Agree. I will get on the basics of this this weekend to at least document the wiki/readme of where we are so folks on't get confused. It won't be anything fancy but the last thing we need is people geting excited about it and then frustrated because the documentation just is mostly irrelevant at this point.
I think Gregg's WEB page and here: https://github.com/DccPlusPlus/BaseStation/wiki Is a good place to start. We can put that in our repo if you want. I think it can be cloned. You should be able to issue PRs to update our Wiki, WEB page, README.md, ,etc. When we get it solid, we can put a banner on Gregg's pages telling people where to find updated information. You are right that the most important thing is to get to the right place and get a zip that they can extract and use our Dex installer or the IDE of their choice to upload. I've issued a PR to the development branch of EX. That adds a few motor boards and changes how current monitoring works. Some of that requires more testing in that the current values come from the current sense specs of the boards or from modeler experimentation and testing. Since some of the current sense modules are notoriously inaccurate, we need good values to plug into DCC++ EX so that A. Over-current protection works properly and B. we correctly sense the ACK pulse when dealing with CVs.
We could add code for calibration. That would work like this: User attaches resistor of known good value (say 1kOhm) on the programming track. Then user issues <C p 1000> command which will measure the voltage on the analog in pin and then calibrate the conversion factor. If the user has a good multimeter with low error percent then the resistor could be measured and then one could issue for example <C p 993> and get a yet better result. Would this be necessary on both programming and main track or are they similar enough so that we can only calibrate one and then use that value for the other? Regards, Harald. PS: I have unfortunately two of the crappy Deek-Robot motor shields which have the L298P chip not correctly soldered to the PCB. So I use the outputs only for programming and for driving a booster which then drives the layout. So yes, folks need advice what motor shields (not) to buy.
Having a calibration option would be nice. At one point I was going to add a track voltage option to DCC++ so it could report both current and voltage. But with a DCC signal, it would take more than a resistor to give the actual track voltage. Measuring the voltage at the Vin to the motor shield at least gives us the power supply voltage. I'm not sure if there is a voltage drop on the track if that is reflected back through the bridge. I'll look at the schematic. But lets' look at that!
The h-bridge IC will indeed cause a difference in the VIN and track outputs. It doesn't matter which h-bridge is used really. One question, why? What does the supply voltage tell you? Similarly the track voltage is not very meaningful since you can not measure it reliably without a circuit *AFTER* the h-bridge and you would only be detecting how efficient the h-bridge is (which is also documented in the datasheet for various h-bridges).
Nothing really Just fluff. I just thought it would be nice for display purposes on a controller/JMRI if it was just one component and a pin to allow us to see the voltage voltage we were using.
While it would be nice to have that sort of reporting it is not possible with off-the-shelf components. I don't expect any user of DCC++EX (or even ESP32 CS) to cobble together special hardware to support every feature of the code.
The H-Bridge should give an almost constant voltage drop of 0.5V or 1.4V (MOSFET or traditonal Transistors ) from the supply voltage. The data sheet should tell. We could probably measure the voltage on the rails. Just measure many times and have a look at the values. It will be obvious which ones are the top values of the rectangle wave and which ones are the "inbetweens". But if you have a stabilized supply voltage (almost all power supplies nowadays have) you can do the calculation with the datasheet once so the feature to measure all the time is not that necessary I think. Regards, Harald.
Not quite sure I follow all of this, but from what we have now from Gregg's code, @haba 's changes and this description, what's the best course? Do we completely re-write the packet code?
That is precisely what I did on the ESP32. I extracted the pre-amble bits pieces entirely as this will simplify the DCC packet logic when generating the data packets. This does add a tiny bit of overhead when transmitting a packet to know if you are in the pre-amble or data segment of the packet, you also need to take into account the extra bits outside of the data bytes of the packet.
https://www.stacken.kth.se/~haba/1zu160/SDS00001.png There are 6 pictures (numbered 1 to 6). I did generate a pulse at the end of the preamble (length as the interrupt function runtime) so that one can look at the DCC output. The first picture should be the idle signal, the other ones are the packet you get from <t 1 1 1 0> Now it's late/early in my TZ, more another day. Goodnight, Harald.
@haba, I guess you got the scope working Wow, look at the overshoot on the first 4 pulses of zeroes in the second byte of the idle packet. Not that bad really, but I wonder why it shows only on the first image? Also, am I reading the packet wrong? The data packet makes no sense to me. I see: Code: 00000001 00111111 00000010 address data checksum And what is picture 5? It shows a single square wave with a pulse underneath it.
Well, the scope got "replacement service" (I bought a new one). The measurements are not on the rail but on the dir pin between the Arduino and the motor shield, so I don't know about the signal quality. I have still to count the bits and see if the packet data actually makes sense, but as I have been running trains with what I think is the code in question I guess it should not be totally wrong. I will double check that. Picture 5 is a zoom into the trigger pulse which is generated by the interrupt routine at bit 14 (end of preamble). Code: ISR(TIMER1_COMPB_vect){ if (mainRegs.currentBit==14) digitalWrite(TESTPIN,HIGH); DCC_SIGNAL(mainRegs,1,14,tickCounter+=) digitalWrite(TESTPIN,LOW); } The transition of the DIR signal should be on the timer interrupt and then the routine starts about 6 microsecods later and runs for 8 microseconds (the one at packet end has more to do and runs up to approx 12 microseconds. Here is a bit pattern for speed 1 loco 3 with the bits combed out: https://habazut.github.io/dcc-ardu/bitpattern.html Regards, Harald.
Hello All, Just arrived late to the party and have been reading through the thread. DCC++ is such a great project and I really appreciate the work you're all doing to stabilize and improve it. I'm using it on a Mega with standard Motor Shield hooked up to JMRI via a Raspberry Pi. I'm at the stage of successfully running a loco via Engine Driver on a Tablet. Have made no attempt to run accessories as yet (see further comments below). My coding knowledge would fit in an ant's lunchbox. So I thought I'd contribute the following instead if someone thinks it worthwhile adding to the docs. One of the things which scared me early on was the thought of having to physically cut the Vin trace and potentially damaging the board. I imagine other novices might feel the same. The way I found around this was to bend the pin on the Motor Shield out so that it can't insert into the socket on the Arduino (see attached photo). A simple fix but that way, the Arduino stays intact and if need be the Motor Shield can be easily restored by carefully re-straightening the pin. Could I also please add: I found the original documentation on adding turnouts and accessories wasn't very clear. If someone has come up with a foolproof single-syllable method, I'd love for it to be included in the revised docs. I'd be happy to help with proof-reading/testing that. Regards, Geoff
LOL! That and your traces look great, Harald! I'm going through your code. What model Siglent scope did you buy? I am trying to get the development branch merged and then change the repository name and make the name changes to DCC++ EX like I did with "Classic". Then maybe we can change the packet generating and ACK code. Thanks for all your work and testing on this.
What would be extra work, but worth the time is to generate timestamps for sending a test batch of packets on a set device (UNO or MEGA) in each version of the code. I would love to know the overhead in both clock cycles and memory for different methods of doing the same thing.
I did buy a SDS1102CML+ It's the second model after the real basic one. Seems to be a decent scope for the price, but one has to search through the Internet to find the PDFs (User Manual, Programming Manual) describing the functions and for some undescribed functions just go through the menus and guess. The expected CD was not in the box. The two probes were included. I have still to explore how the LAN connection works, so far I have transfered the scope images by USB stick (The scope creates files \BMP\SDS000NN.BMP when you press "PRINT") Regards, Harald.
@haba, Did you merge the branch "generatepreamble" into your master? The branches are the same, but I don't see the merge. Are you generating the preamble now more like the description from RoadRailer and that assembly code?
Yes, that was merged but there were no changes on master in the meantime so that's probably why you don't see anything in the merge graph. If there is a PALEN in the DCC_SIGNAL macro then the preamble is generated. I'm utterly bad at assembly, but the preamble is made with R.currentBit < PALEN and then there is a PALEN offset subtracted when accessing the buf holding the bit pattern. I'm currently thinking that we should better document what pins are used for what purpose. For exmple pins 12 and 13 (DIRA. DIRB) which actually are _not_ used on the Arduino but are blocked for other use when the motor shield is inserted and the jumper wires from pin 5 and 10 are set. Actually if you cut the motor shield pins then cables coule be sneaked out to be used for something else. Then there are pins that seem to be tied to the timers and can not be used for something else when the timer is used but I am not quite sure about that. I find the many-use-possibilities of the pins nice but confusing. It would be nice if we could make a used and free pins list. Or is there one and I have not found it yet? Regards, Harald.
