User Interfaces

original source1)

To access the web-interface, enter the IP-address shown on the LCD in your browser. In most cases, the IP-address will be assigned automatically by DHCP. However, if the assignment fails or you don’t have a DHCP-server running in your network, then the controller uses it’s static IP-address. The default one is 192.168.1.235 with a subnet-mask of 255.255.255.0. To access the controller, your computer must be in the same subnet, i.e. with an address of 192.168.1.2.

The web-interface supports modern browsers only. If the browser is too old, some features might not work. For web-developers: The webpages use a lot of CSS and some jQuery. You are welcome to improve or add several functions, especially the signal view, but ask us first. Due to lack of flash memory, some static files are compressed.

Important: The firmware uses LwIP, a lightweight IP-Stack for embedded microcontrollers. We cannot guarantee for 100% security of this stack or our web-server. There is always the possibility of security holes in such implementations, even when authentication methods are enabled. That means, you shouldn’t connect the controller to foreign networks or give access to the controller from the internet with port forwarding. We think the risk of an attack is small, but we would never guarantee that.


Figure 52: The status page of the web-interface


Figure 53: The live signal view of the web-interface

There are two pairs of white dotted lines on the signals page. The are roughly at +/-100mV and +/-500mV. These have no special meaning, but it gives an idea about the scale without looking at the y-axis. If you look at your signals on the server, you'll see two solid white lines which are not sent by your controller, and these happen to lie at the same 'amplitude' points…. that '100mv' based 'relative gain' (along with the 1PPS signal) is the reference that keeps our signal strengths and timings 'relative' to each other in the digital world.

Every of the four user LEDs has a specific purpose:

  • The Green LED starts blinking when the controller receives data sentences from the GPS. It will keep glowing, when the GPS locked the position.
  • The Blue LED flashes every time the controller got a 1PPS signal. That means it should blink exactly every second.
  • The Orange LED flashes every time the controller receives a signal from the amplifiers that reaches the adjusted threshold.
  • The red LED is blinking constantly and slowly if the system has entered the interference mode. If signals cannot be send, i.e. because there is no network connection or no valid GPS signal, then the red LED blinks at the same time as the orange LED.

During boot sequence, the LEDs will be switched on and off on specific steps. If you experiencing problems during boot, you should tell us which LEDs are glowing.


Figure 54: The four SMD LEDs

Pushing the Black Reset Button results in a hardware reset of the CPU. It is independent from the firmware and works always. The Blue User Button has several functions, especially in combination with the LCD. It can also be used to restore the settings to default values, by pushing both buttons together, release the reset button and wait for several seconds until a long beep occurs. The other functions depend on the installed firmware and might be extended in future versions. Refer to the guide in the controllers web-interface for latest information.

During boot, the display shows some status information. After that, and while the system is running, there is a status line at the top and according information on the rest of the screen. The status line shows whether there are pending problems.

The main reason for the LCD is to provide an easy installation and a quick overview of the current status. The system would even work without it. There are much more detailed information visible in the web-interface. Changing configuration cannot be done through the LCD. For latest information about the display, refer to the guide in the controllers web-interface.


Figure 55: The two buttons


Figure 56: The blue LCD showing the signal page

The main purpose of the buzzer is to inform you about status changes. It will beep in high tones on successful actions, on low tones when an error occured and a medium tone during boot. Longer duration of the beep means higher priority.

For example, shortly after the first beep during boot, the buzzer should beep a second time, when an connected amplifier has been identified. If no amplifier is present, it will beep with a low tone. As long as you didn’t solve this problem, the controller won’t detect any strokes. Another example: Beeps for interference mode are slightly shorter, as they can happen from time to time.

The buzzer is connected to the CPUs digital-analogue-converter DAC. That means, it can even play individual sounds. The firmware uses this feature by sending the recorded signals from the ADC to the DAC (when enabled). Thus, it is possible to hear the atmospheric discharges without additional hardware. This is very useful to find a noise-free place for the antennas. Check the web-interface for detailed settings on that feature.

The controller prints several information in its debug log. This happens during start-up, when configuring peripherals, in case of an error or status changes. If you experience problems, these messages can be very helpful. When contacting the developers, you should try add them to your request. There are several ways to view the messages:

  1. Open the debug log on the web-interface and wait for the first messages to appear. Of course it is not possible to view messages when the network connection is not available. Due to technical limitations, some messages might not get transmitted. Note: You have to disable the auto refresh before you can copy the text to clipboard.
  2. Windows users have to install the driver from here. Connect the controller via the micro-USBport to your computer. Enable the virtual-COM-port in the web-interface system settings. A new COM port should be available (check the device manager). You can connect with your desired terminal program (like PuTTY) to this port. Set the baud rate to a desired value (115200 is recommended).
  3. Connect a serial-to-USB converter to the debug port below the LCD. The baud rate has to be set to 115200. Check 4.3.1.10 for hardware details. You will see all messages, even those from early start phase.


Figure 57: A serial-to-USB adapter connected to the controller

In the web-interface settings you can enable more verbose logs. You can use that for further investigations. Please don’t enable them for normal operation, as it can slow down the system dramatically, even when not using one of the methods above!