Use ring buffer to broadcast messages from WiThrottle such as power status, speed, direction, turnout state

[davidcutting42]

From #66

[Asbelos]

This would depend on not having ethernet and wifi at the same time.. and also on the network stack redesign by @grbba

[grbba]

What does that actually mean ? WiThrottle send something else than the actual WiThrottle protocol to the CommandStation ?
What does that to the User Experience and why would/do I need it ?

[Asbelos]

On a java withrottle server the server would broadcast these things to all attached clients.. we could not do that with our original wifi implementation so we had to only send these when a client polled. With the ringbuffer implementation it becomes possible to send these broadcasts without waiting for a poll. No  change in Ed, user perhaps sees a slightly crisper response. On 22 Nov 2020 20:32, Gregor Baues <[email protected]> wrote: What does that actually mean ? WiThrottle send something else than the actual WiThrottle protocol to the CommandStation ? What does that to the User Experience and why would/do I need it ? —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

[grbba]

So what you are basically saying is that the CS is issuing messages to all connected WiThrottle clients without having received a command before based e.g. on a timer or some other trigger operating in the CommandStation is that right ?

[Asbelos]

Currently CS only responds to being polled.. if we send the info when it changes then the polling frequency could be  reduced for less overheads. On 22 Nov 2020 21:05, Gregor Baues <[email protected]> wrote: So what you are basically saying is that the CS is issuing messages to all connected WiThrottle clients without having received a command before based e.g. on a timer or some other trigger operating in the CommandStation is that right ? —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

[grbba]

Sounds reasonable but the only observation i would have is to look into the trade off between the cost off polling and the cost of having the observers looking for changes in the data you want to send. Obviously this can be done this way and indeed would be nice. Second observation would be if the current WiThrottle based clients can handle this type of async data flow ( ED and WiThrottle maybe but all the others around maybe not and i can't remember if in the Doc about WiThrottle on the JMRI website that sort of capability is actually required by the protocol )

[marada1]

We have been playing around with the NRF network and CS. The polling does not seem to be an issue so far. The issue so far is communicating to the NRF board. Using a mega and the NRF boards they share a serial port. The solution is to remove the NRF board from the CS which is a good idea and have the CS communicate to the NRF network using serial2 in the case of the Mega or software serial using an Uno. But when the 2 were combined and the serial part disabled, it worked.