You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we communicate between the SBC and controller micro using a "console" (really just direct access to the UART line). rno-g-lted also sometimes sends LTE control messages (spamming the console).
We want to multiplex this interface, allowing for on-SBC collection of environmental data as well as a more robust interface for commanding (so eventually we could have an automatic station start script).
This will probably require some daemon to "own" the UART connection, but we want to retain the console for compatibility and such, so will need some IPC (maybe dbus, maybe something else). We probably don't need to support programming the microcontroller via this interface, though we could.
There was an early attempt at this by @cozzyd, although it's not clear if it's the right level of control.
The text was updated successfully, but these errors were encountered:
Currently, we communicate between the SBC and controller micro using a "console" (really just direct access to the UART line). rno-g-lted also sometimes sends LTE control messages (spamming the console).
We want to multiplex this interface, allowing for on-SBC collection of environmental data as well as a more robust interface for commanding (so eventually we could have an automatic station start script).
This will probably require some daemon to "own" the UART connection, but we want to retain the console for compatibility and such, so will need some IPC (maybe dbus, maybe something else). We probably don't need to support programming the microcontroller via this interface, though we could.
There was an early attempt at this by @cozzyd, although it's not clear if it's the right level of control.
The text was updated successfully, but these errors were encountered: