search

Openvario / sensord

Daemon to poll air data from Openvario sensorboard
6 stars 11 forks source link

sensord should be a server, not a TCP client #42

Closed MaxKellermann closed 2 years ago

MaxKellermann commented 2 years ago

The current layout is that sensord connects to variod, but it makes more sense to auto-start sensord as a systemd socket unit as soon as variod attempts to connect to its address. That would allow us to eliminate all of the socket code, and would make debugging sensord much easier, because you can just launch it on the command line, and it would spit NMEA on stdout.

hpmax commented 2 years ago

Sensord (and variod) can be started on the command line and I believe it can spit NMEA out to either stdout or a log file. Have to look up the exact options. Can't comment on the rest of it.

MaxKellermann commented 2 years ago

There's the -r option but it records some weird format to the given file, not NMEA. sensord still requires an outgoing variod connection or else it won't do anything; recording to the file works only while the connection to variod exists. This design is much more complicated than it needs to be. With my idea, a lot of code can simply be deleted.

linuxianer99 commented 2 years ago

There's the -r option but it records some weird format to the given file, not NMEA. sensord still requires an outgoing variod connection or else it won't do anything; recording to the file works only while the connection to variod exists. This design is much more complicated than it needs to be. With my idea, a lot of code can simply be deleted.

The idea behind this -r option was to record exact the same data, as the sensor will deliver on the i2c. If we collect NMEA, all filters are done and it is not possible to replay a flight on the desk while testing new filters ...

But I agree with you @max, if we can simplify the communication, we should do this ... XCSoar is able to connect to a server as well, right ?

MaxKellermann commented 2 years ago

But I agree with you @max, if we can simplify the communication, we should do this ... XCSoar is able to connect to a server as well, right ?

That would be another idea: let variod and XCSoar both connect to sensord. Right now, sensord and XCSoar both connect to variod, which is a weird topology.

Making sensord a TCP server which allows multiple connections however would complicate the sensord code (but it makes sense). It would require sensord to establish an I/O event loop which handles the listener socket, all established connections and the I2C sensors.

hpmax commented 2 years ago

@MaxKellermann I'll admit to ignorance on the Linux particulars, but I agree that the system as it stands is... ugly. Sensord passes data to variod which in turn uses it and passes data along to XCSoar. While I'm not a real fan of this topology, there are things to keep in mind.

XCSoar needs to be able to talk to variod (to tell it to increase/decrease volume for instance). Both XCSoar and variod need to be able to talk to sensord (although at present XCSoar talks to sensord through variod acting as a relay). Turning XCSoar into a server and then having both XCSoar and Variod talk to sensord, but no communication between variod and XCSoar doesn't really fix things.

I think the best solution, would be to integrate variod into XCSoar.