Well really from what I can tell from the spec, the packets continue to be resent to the locomotive that is active at the time for several reasons. One is because you must continue to apply power to the rails or none of the locomotives will move, and since locomotives ignore packets not bound for them, this supplies that need by basically continuing to send the packet to the active locomotive (decoder function updates, speed / direction updates, etc.) The power from the rails coming in (square-wave ac) is then full-wave rectified at the decoder to provide a constant power source to the decoder, locomotive, and accessories. The second reason is because model railroad track can be a woefully inefficient conductor (dirty track, dips in track, poor locomotive wheel contact) so a packet may be missed. The decoder has no specified way to allow the controller to know that it received the packet, so updates are continually sent to the active locomotive. It actually works really well in practice; DCC control is pretty great for modelers. I think once I get the rest of my components I will try to implement it and see if it fits my needs. I knew that the issue would be that the kernel would serve other needs as they arose (I have a pretty decent software design background and I do hobby operating system development as a side project) and that no timing precision was guaranteed. I will look into the possibility of on-board timers that would give me at least a decent level of resolution to fit this need before trying to delve into the many wonders of the onboard PRUs.
On Sun, Feb 7, 2016 at 1:05 PM, William Hermans <[email protected]> wrote: > *I'm not sure that the usleep function (or nanosleep) can provide the >> microsecond resolution I need here.* >> > > It can, but can never be guaranteed. The problem here is kernel latency. > Which can be mitigated some by using an RT kernel. > > *The DCC spec also says that the packet should be resent several times to >> ensure packet delivery, so would it be possible to get this to work using >> the usleep() or nanosleep() timer and GPIO pins with this kind of accuracy >> if I am resending the packets, say, 10 times? I am currently reading >> through Derek Molloy's book on the beaglebone so if I have to do something >> like use the PRUs I will do so, but I am really new to all of this and the >> amount of information out there is just overwhelming! Advice on how to >> proceed is of course greatly appreciated. Thanks!* >> > > No idea of this DCC spec, but resending packets "just in case" is terribly > inefficient. usleep() / nanosleep() are Linux API functions, which could be > replaced by using a hardware timer from the Beaglebone. Here, I personally > have zero experience, so I'm not sure how to implement such, or how well it > would truely work out. I can say after reading some of DR Molloy's > companion web page for his book. One can create a high resolution / highly > accurate timer using a PRU. > > How I would recommend proceeding . . . is to learn more about the Linux > programming interface ( API ), and experiment. Only you truly know what > *you* want, or need. If using a PRU is required for timing, that is fine, > but do know that communications between Linux, and the PRU can still > present *some* latency issues. Whether these latency issues present a > problem for your project now, is something only you can really answer. > After all, there is nothing that is truly real time, only degrees of "real > time enough". > > On Sun, Feb 7, 2016 at 5:07 AM, Benjamin Melikant <[email protected]> > wrote: > >> Hi everyone! I am new to embedded linux systems and the beaglebone black. >> I have had some interest lately in creating a DCC model railroad controller >> for a while now, and while I have seen examples out there for Arduino and >> the RPi, not much is out there in the way of handling something like this >> on the beaglebone. The DCC signal is sent to the locomotives through the >> track via square-waveform AC in the voltage range of +-8v to +-22 v. A >> binary 0 is represented by a 100 microsecond +v, and a 100 microsecond -v, >> and a 1 is 58 microseconds +, -. My plan was to use an H-bridge setup to >> provide the +15v to the tracks, and use a GPIO pin on the board to control >> the h-bridge. One example I saw in Python for the RPi used a for loop to >> write the binary information in a similar fashion to this (c-type code >> below): >> >> string bit_pattern = "111111111100100101"; // example string >> >> for (int i = 0; i < bit_pattern.length(); i++) { >> >> if (bit_pattern[i] == '1') { >> >> writePin (WHICHEVER_GPIO, PIN_HIGH); >> usleep (binary_one_delay); >> // delay for ~58 microseconds >> writePin (WHICHEVER_GPIO, PIN_LOW); // >> turn the pin back off >> usleep (binary_one_delay); >> // and delay again to represent 1 >> } >> >> else if (bit_pattern[i] == '0') { >> >> // same as above, using different delay pattern >> } >> } >> >> // the DCC spec says there must be a delay here, I think it was 20 >> microseconds minimum? >> usleep(packet_space_delay); >> >> >> I'm not sure that the usleep function (or nanosleep) can provide the >> microsecond resolution I need here. The DCC spec also says that the packet >> should be resent several times to ensure packet delivery, so would it be >> possible to get this to work using the usleep() or nanosleep() timer and >> GPIO pins with this kind of accuracy if I am resending the packets, say, 10 >> times? I am currently reading through Derek Molloy's book on the beaglebone >> so if I have to do something like use the PRUs I will do so, but I am >> really new to all of this and the amount of information out there is just >> overwhelming! Advice on how to proceed is of course greatly appreciated. >> Thanks! >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to a topic in the > Google Groups "BeagleBoard" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/beagleboard/7385vSRF5DY/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
