Asbelos
commented
3 years ago Technically, we could even discard the current packet part way through if the new packet is more important.
If the current packet is still preambling, nothing would notice because we could switch the data part without restarting the preamble.
Even if the current packet was partially transmitted we could start again with a new preamble, decoders and sniffers will see an invalid packet
Having just seen the query about huge layouts and large numbers of locos set me thinking about what happens if we get a fast stream of throttle commands from jmri. At present this is self throttling as a throttle command will block temporarily if there is already a dcc packet waiting to start transmission. Of course we can't speed up dcc but It seems there are a couple of cunning tricks we could play to help a bit in extreme cases: At any time there is a packet being transmitted and maybe a packet buffered ready to go. The reminder loop adds a reminder packet if there is NOT a packet waiting to go...
Now, if we get a throttle command arrive while there is a packet waiting to go, then the loop will block until the current packet is complete and the waiting packet has been moved up to current. This means we could detect the situation where a new throttle command is blocked because the waiting packet is actually a reminder.. so we could replace the waiting reminder with the new throttle packet and get it transmitted one packet earlier.
When you hit max dcc there's is one thing we can do about it; We should not send a throttle cmd that matches the reminder for this loco... AND If we hit max dcc we could switch down to 28 step mode SO throttle cmds are more likely to be the same as the reminder... And the packets are shorter than a 128 speed step packet Q. What will people think of being "throttled" back in terms of speed steps?