Wiznet makers

Overview

This project shows how a Korean maker used WizFi360 to connect a custom astronomy device to N.I.N.A., an open-source application that automates astrophotography by controlling equipment such as cameras, telescope mounts, focusers, filter wheels, domes, and calibration devices from a single interface.

Instead of creating a custom PC application, the maker implemented the ASCOM Alpaca protocol so the device appears as a standard network accessory that N.I.N.A. can automatically discover, connect to, and control over Wi-Fi.

The device being developed is a Cover Calibrator—a controllable flat-field light source that provides uniform illumination for telescope calibration and can optionally include a motorized cover. During an imaging sequence, N.I.N.A. can detect the device, monitor its status, and automatically adjust the panel brightness or operate the cover.

In this project, WizFi360 serves as the Wi-Fi communication interface. Using simple UART AT commands, it carries Alpaca UDP discovery packets and HTTP/JSON API traffic between the PC and the embedded controller.

                 N.I.N.A.
      (Astronomy Automation Software)
      ├─ Camera
      ├─ Telescope Mount
      ├─ Focuser
      ├─ Filter Wheel
      ├─ Dome
      └─ Cover Calibrator  ← This Project
                 │
          ASCOM Alpaca
                 │
             Wi-Fi (WizFi360)
                 │
       Embedded Controller
                 │
      Light Panel / Cover

Why Build This?

When photographing galaxies or nebulae, astronomers must also capture flat frames to remove dust spots, uneven illumination, and optical vignetting from their images.

A Cover Calibrator makes this process automatic by placing a controlled light source in front of the telescope. Instead of manually turning on a light panel or adjusting brightness, imaging software can perform the entire calibration sequence automatically.

Commercial Cover Calibrators already exist, but they can be expensive and are often mounted permanently on the telescope, increasing weight and mechanical complexity.

The maker instead designed a Wi-Fi controlled version that can be installed inside the observatory dome and operated remotely.

The intended workflow is simple:

1. N.I.N.A. searches the local network.
2. The custom controller announces itself as an Alpaca device.
3. N.I.N.A. connects automatically.
4. It reads the current device status.
5. It adjusts panel brightness or cover position.
6. The controller operates the hardware.

The public post mainly demonstrates the networking and protocol stages (steps 2–4). The lighting hardware and mechanical cover are still under development.

Why Is This Interesting?

This is much more than a simple Wi-Fi module demonstration.

The author's blog focuses on real observatory automation, including:

• ASCOM
• ASCOM Alpaca
• N.I.N.A.
• Auto Focusers
• Telescope Mounts
• Dome Controllers
• Cover Calibrators
• All-Sky Cameras

That makes WizFi360 part of a complete astronomy-control ecosystem rather than just another UART-to-Wi-Fi example.

The project demonstrates how an embedded device can integrate directly with existing astronomy software without requiring users to install a separate control application.

The public source does not identify the MCU or controller hardware, so the example should be understood as a protocol and networking demonstration rather than a complete hardware reference.

Understanding the Software Stack

N.I.N.A.

N.I.N.A. (Nighttime Imaging 'N' Astronomy) is an open-source application used by astrophotographers to automate telescope operation.

Instead of manually controlling each device, users operate everything from one interface—including cameras, focusers, filter wheels, domes, and Cover Calibrators.

In this project, N.I.N.A. is the client application that discovers and controls the device.

ASCOM Alpaca is a standardized network protocol for astronomy equipment.

Rather than creating proprietary software for every device, manufacturers implement the Alpaca API so that applications like N.I.N.A. can automatically discover and communicate with compatible hardware using standard UDP discovery and HTTP/JSON requests.

In this project, the embedded controller behaves as an Alpaca device server.

WizFi360 provides the Wi-Fi connection between the embedded controller and the observatory network.

Using UART AT commands, it:

• Joins the local Wi-Fi network
• Receives Alpaca discovery packets (UDP)
• Accepts HTTP connections from N.I.N.A.
• Transfers HTTP/JSON messages between the PC and the embedded controller

The application logic runs on the controller, while WizFi360 serves as the network communication interface.

System Architecture

The public evidence confirms the network and API portions. The physical-output portion remains a planned or partially documented stage.

How the WizFi360 Network Path Works

1. Joining the Wi-Fi network

The log begins by disabling command echo and placing WizFi360 in Station mode:

ATE0
AT+CWMODE_DEF=1

It then connects to an access point:

AT+CWJAP_DEF="HOME", ...
WIFI CONNECTED
WIFI GOT IP

An IP-status query returns the assigned address, gateway, and netmask.

This is consistent with WizFi360 Station-mode operation: the module joins an existing wireless LAN and can obtain network configuration through the access point.

2. Enabling multiple network connections

The source enables multiple connection mode and asks WizFi360 to include remote-address information with received data:

AT+CIPMUX=1
AT+CIPDINFO=1

This is useful because the controller needs to distinguish discovery traffic from subsequent HTTP client connections.

The project uses WizFi360’s normal AT-command transmission model. Incoming data appears through +IPD, while outgoing responses are sent with AT+CIPSEND. WIZnet’s documentation describes the same receive and send mechanism for normal transmission mode.

Alpaca Discovery

The most important source evidence is the discovery exchange.

The controller receives:

alpacadiscovery1

It then returns:

{"AlpacaPort":5000}

This tells the Alpaca client that an Alpaca device server is available and that its management and device APIs can be reached on TCP port 5000.

ASCOM’s discovery mechanism is intended to locate Alpaca servers on the same local network or VLAN. After discovering the server address and port, the client can query the management API to determine which devices are exposed.

This exchange is the clearest proof that WizFi360 is not being used merely to obtain an IP address. It carries the actual device-discovery protocol required by the astronomy application.

Alpaca Management API

After discovery, N.I.N.A. opens an HTTP connection and requests the server’s API information.

API versions

GET /management/apiversions HTTP/1.1

The controller returns:

{
  "Value": [1],
  "ClientTransactionID": 0,
  "ServerTransactionID": 1,
  "ErrorNumber": 0,
  "ErrorMessage": ""
}

Server description

GET /management/v1/description HTTP/1.1

The response identifies the experimental endpoint as:

{
  "ServerName": "NB CoverCalibrator Alpaca",
  "Manufacturer": "NoBrand",
  "ManufacturerVersion": "1.0",
  "Location": "Unknown"
}

Configured devices

GET /management/v1/configureddevices HTTP/1.1

The server reports one configured device:

{
  "DeviceName": "NBC",
  "DeviceType": "CoverCalibrator",
  "DeviceNumber": 0
}

This sequence proves that the controller presents itself as an Alpaca server rather than as a generic serial-over-Wi-Fi bridge.

Cover Calibrator Device API

Once N.I.N.A. recognizes the device, it begins querying the cover-calibrator API.

The log contains requests for:

• connected
• calibratorstate
• maxbrightness
• brightness
• coverstate
• description
• driverinfo
• driverversion
• supportedactions

A connection request appears as:

PUT /api/v1/covercalibrator/0/connected HTTP/1.1

with:

Connected=True

The controller responds with an Alpaca transaction result showing no error.

N.I.N.A. then repeatedly reads device state:

GET /api/v1/covercalibrator/0/calibratorstate
GET /api/v1/covercalibrator/0/brightness
GET /api/v1/covercalibrator/0/coverstate

The sample responses indicate:

• Calibrator state value: 1
• Maximum brightness: 255
• Current brightness: 0
• Cover state: 0

The exact interpretation of each numeric state should follow the ASCOM CoverCalibrator interface definitions. The important source-backed result is that N.I.N.A. accepts the endpoint and continuously polls its properties through the WizFi360 network path.

Why N.I.N.A. Generates So Many Requests

The author notes that N.I.N.A. issues many commands in rapid succession and expects the device to respond consistently.

That observation is technically useful. An embedded Alpaca server must do more than return a single successful discovery packet. It must handle repeated HTTP requests, preserve transaction IDs, produce correctly formatted JSON, and avoid blocking while the client polls multiple properties.

The observed traffic pattern is approximately:

Connect device
      │
      ├─ Read connection state
      ├─ Read calibrator state
      ├─ Read maximum brightness
      ├─ Read current brightness
      ├─ Read cover state
      ├─ Read device information
      └─ Repeat operational state polling

This makes the project a practical protocol-validation exercise for WizFi360 and a constrained embedded controller.

Role of WizFi360

WIZnet role: WizFi360 provides the wireless IP interface that allows an embedded astronomy controller to appear as an ASCOM Alpaca device on the observatory network.

Its role can be divided into four layers.

1. Wireless LAN attachment

WizFi360 joins the existing observatory access point and obtains network connectivity.

2. UDP discovery transport

It receives the Alpaca discovery datagram and transmits the JSON response containing the server port.

3. TCP transport for HTTP

It accepts client connections used for Alpaca management and device API requests.

4. Serial network offload

The embedded controller interacts with the network using AT commands rather than implementing a Wi-Fi MAC, TCP/IP stack, and socket layer directly.

WizFi360 supports UART control, TCP server/client operation, UDP communication, and multiple simultaneous links, matching the basic communication requirements shown in the source log.

The application logic still belongs to the host controller. WizFi360 does not implement ASCOM Alpaca itself; it transports the requests and responses generated by the controller.

Why This Is a Useful WIZnet Maker Example

Many Wi-Fi-module examples stop after:

• Joining an access point
• Opening a TCP socket
• Sending a simple web request

This source goes further. It applies WizFi360 to a specialized device ecosystem with a defined discovery process, management API, device classification, transaction handling, and repeated property polling.

The educational value is the complete application path:

Astronomy application
        │
ASCOM Alpaca protocol
        │
HTTP/JSON and UDP discovery
        │
WizFi360
        │
Embedded controller
        │
Observatory equipment

It is also a useful example of how a maker can expose a custom device to existing PC software without writing a proprietary desktop application.

Wi-Fi Instead of Wired Ethernet

The author states that a wired network could support Alpaca, but chose Wi-Fi because the intended installation is associated with a moving observatory dome.

That decision illustrates an appropriate use of WizFi360:

• The application requires IP compatibility.
• Physical cable routing is inconvenient.
• Traffic volume is small.
• Local network coverage is available.
• The device needs to integrate with existing TCP/UDP software.

This is not a Wi-Fi and Ethernet hybrid design. The demonstrated path is a single Wi-Fi network connection through WizFi360.

Source Evidence

All of these items appear directly in the posted WizFi360 communication log.

Limits of the Public Source

The post is explicitly described as preparation work, so it should not be presented as a completely finished cover-calibrator product.

The source does not clearly provide:

• Host MCU or controller-board model
• Circuit schematic
• WizFi360 wiring diagram
• Complete firmware source
• Flat-panel driver circuit
• Motor or cover mechanism
• Final hardware photographs
• Long-duration reliability test
• Finished N.I.N.A. calibration sequence
• Public repository or license

There is also a port detail that should be checked before reproducing the setup. The discovery reply advertises Alpaca port 5000, while one AT-command line references server port 5500. The log may combine different test stages or an already-running server configuration, but the public post does not explain the difference.

For this reason, the project should be classified as an ASCOM Alpaca network proof-of-concept and controller preparation log, not yet as a complete build guide.

Upgrade Ideas

A follow-up version would become substantially easier to reproduce with the following additions:

1. Identify the host MCU and controller board.
2. Publish the UART connection and power schematic.
3. Document the final TCP and UDP port configuration.
4. Separate the Alpaca protocol parser from the WizFi360 AT-command layer.
5. Publish a minimal firmware repository.
6. Add brightness-control hardware and example commands.
7. Add cover-open and cover-close mechanism testing.
8. Show the device inside N.I.N.A.’s equipment screen.
9. Run an automated flat-frame sequence.
10. Add reconnect and timeout behavior for temporary Wi-Fi loss.

Related WIZnet Maker Reading Path

WizFi360 AT Command Projects

These are useful for understanding Station mode, TCP servers, UDP communication, and serial AT-command handling before implementing a higher-level protocol.

Arduino Observatory Controllers

Arduino-based dome, weather, focuser, and relay-controller projects provide the nearest application context. They show how small controllers can automate physical observatory equipment.

W5500-Based ASCOM Alpaca Endpoint

A wired version using W5500, W5100S, or W55RP20 would be a useful companion project where fixed observatory equipment does not require wireless movement.

MQTT Observatory Monitoring

MQTT would complement, rather than replace, Alpaca. Alpaca can handle standardized astronomy-device control, while MQTT could publish environmental telemetry, alarms, and equipment status to a dashboard.

Source-Backed Summary

This project demonstrates an early-stage ASCOM Alpaca cover-calibrator controller using WizFi360 as its Wi-Fi network interface.

The WizFi360 module joins a local access point, receives an Alpaca discovery request, and returns the TCP port of the experimental device server. N.I.N.A. then accesses the server’s management endpoints and recognizes a CoverCalibrator device. The communication log also shows repeated HTTP requests for connection, brightness, calibrator state, cover state, driver information, and supported actions.

Its strongest WIZnet Maker value is not the unfinished lighting hardware. It is the successful integration of WizFi360 with a specialized network-control standard used in astronomy automation.

Its main limitation is reproducibility: the host controller, circuit, complete firmware, and finished mechanical system are not publicly documented.

Related WIZnet Maker Project

https://maker.wiznet.io/TheoIm/projects/osc%2Dkeypad%2Donyx/ : Like the N.I.N.A. project, it is a Human Interface application that converts physical user input into standardized network commands to control professional software.

FAQ

Q. What is being built?

A custom flat-field cover calibrator intended for remote operation inside an astronomical observatory.

Q. What does WizFi360 do?

WizFi360 connects the embedded controller to the local Wi-Fi network and transports Alpaca UDP discovery and HTTP/JSON API traffic.

Q. Does WizFi360 implement ASCOM Alpaca internally?

No. The host controller must generate and process the Alpaca protocol. WizFi360 provides the network communication layer.

Q. How does N.I.N.A. find the device?

N.I.N.A. sends an Alpaca discovery request. The controller receives it through WizFi360 and replies with JSON containing the Alpaca server port.

Q. Which device type is exposed?

The management response identifies device number 0 as a CoverCalibrator.

Tags

#WizFi360 #ASCOMAlpaca #NINA #Astrophotography #ObservatoryAutomation #CoverCalibrator #EmbeddedSystems #WiFi #HTTP #UDP