Request: Add IP timer connection method

[Jchuchla]

Serial over IP links are commonplace these days. IP based connections can be wired or wireless, and you can establish connections from devices with no serial or USB ports. One popular and low cost implementation is the Espressif ESP platform. Many of their products ship by default with a serial over IP firmware. https://github.com/espressif/esp-at

A $3 ESP-01 module could easily be connected to a track timer and provide a wireless IP connection to the timer. https://www.amazon.com/MakerFocus-Wireless-Transceiver-DC3-0-3-6V-Compatible/dp/B01EA3UJJ4?th=1

The firmware is initially configured via its serial interface using an AT command set.
https://docs.espressif.com/projects/esp-at/en/release-v2.2.0.0_esp8266/AT_Command_Set/index.html.

Users would configure the serial parameters to connect to the timer, and then set the WiFi and IP parameters. This is stored in nonvolatile memory and from there on out no further configuration is needed.

The module can be configured in multiple ways, but for the purpose of a track timer, either the TCP server, or TCP client would likely be the most appropriate. In the TCP server mode, the ESP would wait for connections from DerbyNet. In the TCP client mode, the ESP would initiate the connection to a TCP server running on the DerbyNet system. I could see advantages of either method. If the DerbyNet address is likely to change, then it would be better for DerbyNet to reach out to the ESP. If the DerbyNet address is likely to be fixed, then the ESP could be configured to initiate the connection to derbynet.

In a perfect world, both client and server mechanisms would be nice options to have. However, I think that it would be better to configure the connection to the timer in DerbyNet since users already need to be equipped to interact with the DerbyNet platform (and may not have a serial programmer to interact with the ESP) So I think the ESP running as a TCP server is best. DerbyNet would establish the outbound connection to the ESP.

Once the connection is open, the protocol between the timer and DerbyNet would be the same as if it were serial. It's just being transported over a TCP connection rather than a serial connection.

If we wanted to get fancy, the timer connection code in DerbyNet could implement a discovery mechanism by testing TCP connections to every address on the subnet and if a connection is successful, then attempt to discover the timer thru that connection.

MQTT is also a supported communication method, but I can't think of any significant advantage of using this. It would require an MQTT broker on the network with a known address. The only situations where this might be useful is if one track needed to be monitored/controlled by multiple software applications.

From a DerbyNet point of view, there's no need to worry about the timer connection hardware config except for maybe a tutorial to get people started. All I'm asking for here is to just provide a TCP based connection option in additional to com ports in the timer app. I've just provided all the additional background info to explain the possible applications.

[jeffpiazza]

I take your point that there are devices for conveying serial streams over TCP, but I'm not sure I understand what benefit this offers. Certainly TCP can relayed over longer distances (around the world), but otherwise I'm not really seeing your point.

Since physical serial ports are virtually unknown in modern hardware, almost all timer users presently use USB-to-serial adapters, with drivers which present a virtual serial port to the host OS. Surely there are similar virtual device drivers to present serial-over-TCP as virtual serial ports, without burdening the application with having to support wholly separate code paths? In other words, why does the application have to be aware that it's not actually using a serial connection?

Much more interesting, from my point of view, would be a small SoC device that plugs in to the timer but then speaks HTTP directly to the DerbyNet server, and eliminating the need for either the in-browser interface or the derby-timer.jar. It's already possible to configure Raspberry Pis in this role, but the Pi is overkill (and unobtainable until they solve their supply chain woes).

[Jchuchla]

My biggest motivation with this regard is to eliminate clutter in the area of the timing gate. The finish line is a busy area on race day and extra devices and cables in that area are prone to be tripped on. We currently have our gate connected to the onboard serial port on the header pins of a pi. And currently, this pi is the same one running the derbynet server. So we need to have that pi and the wifi router in close proximity to the gate causing the unwanted clutter. So that’s why I’m thinking toward the wireless IP method integrated into the gate itself. So I’m thinking of integrating an ESP01 directly into the gate so that we don’t need any cables connected at that end. According to the docs for the ESP, their out of the box firmware looks to only work for UART to socket passthru when it’s set up in the client mode. Which means that a TCP server needs to be listening on the other end. Though I haven’t tested that yet and I suspect it may actually work either way. I was hoping to stick with the stock ESP firmware as that’s a low bar of entry to other users. But the same ESP board could run alternate firmware like Tasmota or ESPEasy which could open the door to other connection methods.

I’m an audio visual control systems programmer by day. I loathe USB to serial adapters. There always seems to be a driver issue, or flaky USB connection or something getting in the way of a stable and reliable connection. We used to use a serial to usb adapter connected to a laptop for our track timer interface, but it was always disconnecting and causing headaches on race day. That’s why we switched to the pi at the finish line with the hardware serial port. But that’s just a side soapbox rant.

Your point about VCPs being a standard intermediary is mostly sound though I’m not sure how well that translates across platforms when it comes to non-driver based VCPs. My initial research is showing that you need to use different mechanisms to virtualize an IP port as a VCP on different OSes. That seems like it would be harder to support. It feels like rolling an TCP listener into the java app would be a more platform universal approach, hence the feature request here.

I was actually thinking about replacing the entirety of the timer’s guts with an ESP. An ESP32 is vastly more powerful than the pic chip currently at the heart of my gate. It could certainly do it all in one chip. But I’m not completely sure that it could still manage 5 digit timing precision while managing WiFi and doing http transactions too. Doing this would be a bigger project that would require a circuit design and fab as well as a full firmware implementation for the ESP. It’s a compelling idea, but not a project I’ve got time for at the moment.

There’s also the supportability of such a thing. The thing about cub scouts is there’s always high turnover. I’ve got 6 more years in this pack, but then I need to hand it off. I hate to hand off something to the next guy that was home-built with no support channel. I have no interest in selling pinewood derby gates or maintaining the infrastructure to support an open source thing like that. This is what led me back to the simple serial WiFi adapter. That keeps the support of the gate itself with the gate manufacturer. And the user could always fall back to USB/serial if there’s a problem with the WiFI adapter.

So back to the topic at hand. I think I may have figured out a simple way to virtualize a IP port as a tty in linux using socat. That wouldn’t work for windows, but it will suit my needs on a pi. It would be something like this: socat -d -d TCP-LISTEN:8181,reuseaddr,fork,su=nobody PTY,link=/dev/ttyV1,waitslave,echo=0,raw,perm=0777 Then derby-timer just needs to connect to /dev/ttyV1 and it should work.

My big problem at the moment is that I can’t get derbynet-timer working on the pi I have on hand (Pi 2). It’s currently only running in simulate mode. So I’m kinda at a standstill until I can get a newer pi on the bench to test with. I suppose I could fire up an esp, connect it to the gate and use a modified version of the socat command to route the output to the console just to verify that part of the link works. But getting it into derby-timer will have to wait till I can get it running and talking to a vcp.

From: Jeff Piazza @.> Sent: Thursday, January 26, 2023 7:27 AM To: jeffpiazza/derbynet @.> Cc: Jon Chuchla @.>; Author @.> Subject: Re: [jeffpiazza/derbynet] Request: Add IP timer connection method (Issue #233)

I take your point that there are devices for conveying serial streams over TCP, but I'm not sure I understand what benefit this offers. Certainly TCP can relayed over longer distances (around the world), but otherwise I'm not really seeing your point.

Since physical serial ports are virtually unknown in modern hardware, almost all timer users presently use USB-to-serial adapters, with drivers which present a virtual serial port to the host OS. Surely there are similar virtual device drivers to present serial-over-TCP as virtual serial ports, without burdening the application with having to support wholly separate code paths? In other words, why does the application have to be aware that it's not actually using a serial connection?

Much more interesting, from my point of view, would be a small SoC device that plugs in to the timer but then speaks HTTP directly to the DerbyNet server, and eliminating the need for either the in-browser interface or the derby-timer.jar. It's already possible to configure Raspberry Pis in this role, but the Pi is overkill (and unobtainable until they solve their supply chain woes).

— Reply to this email directly, view it on GitHubhttps://github.com/jeffpiazza/derbynet/issues/233#issuecomment-1405006919, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABMSGQFEDYCXWXZQF3JISNDWUJ3TXANCNFSM6AAAAAAUGVFKCE. You are receiving this because you authored the thread.Message ID: @.**@.>>

[jeffpiazza]

I think this speaks to how the pi might be able to view a serial-over-tcp stream as a virtual serial device, which would then work with DerbyNet without special support: https://stackoverflow.com/a/22689163