Files for ordering
Closed this issue · 38 comments
Hi!
I really love your idea of a homebrewn decoder, but I'm more a software guy and have issues producing the files needed to order pcb's (I've tried jlcpcb). Producing the gerber files worked, but creating the placement files showed that 1) I have issues selecting the right parts because of footprint and 2) one component was not available (U3 in the right footprint format) and 3) the placement was very off (I think because of negativ Y position, but I'm not really sure because I also had to mess a lot with the files to get the webservice accepting the files).
In short, I really want to have some decoders to test them, but I feel uneasy with no prepared files which are known to work... Getting the files per email would also be fine, you can find my email address on my website which is linked in my github profile..
Thanks for this great project!
-Kai
Hey Kai,
Thank you for the interest. There are a few things to note about production files for JLCPCB. The following links should contain all the necessary information:
https://support.jlcpcb.com/article/194-how-to-generate-gerber-and-drill-files-in-kicad-6
https://support.jlcpcb.com/article/84-how-to-generate-the-bom-and-centroid-file-from-kicad
I have also attached the production files.
Production_Files.zip
You may need to rotate some components in JLCPCB's component placement preview. When choosing capacitors, also consider the maximum voltages.
Edit:
If there are any ambiguities regarding the selection of components, here is a picture of components selected as an example:
Edit 2:
Here is a picture showing the placement. It's best if you check it again if I've made a gross mistake in component selection or placement. Pin 1 is always marked with the dot.
Gabriel
great, thanks for all the infos! will try tonight to order some boards...
the pictures really helped me ordering some boards to test them, many many thanks for providing them! one feedback I got: even though the placements were shown correctly in the web-preview it needed to be corrected manually by an engineer on their side, not sure why. and they replaced the D1 by "FUXINSEMI KMB24F".
An idea for improvement would be to integrate a way over custom commands to be able to update the software on the decoder without opening the train via the programming track and special custom software running on the dcc-ex.
I owe you one or two beers for the project and your help! If you're around Karlsruhe drop me a note ;)
is there a possibility to get more switches by using more gpios easily?
I don't quite understand, the software can only be changed or programmed via serial wire debug. What do you mean with the special custom software that is on the dcc-ex? Do you perhaps mean the configuration variables or are you talking about the software as a whole? With regard to the switches, it is possible to implement additional switches, but the PCB would have to be modified for this, since not all pins are brought out on a pad.
I was thinking that for the very first time you still need the serial wire debug, but afterwars the software can flash itself via a special protocol implemented in this decoder and for example on the dcc-ex as this is also opensource. I assume currently to apply an updated firmware you need to open the train and solder something to be able to use the serial wire debug.
let's wait until I get my first batch of decoders to find out if that is really needed or not.
Received my batch, not tested yet. Two points: when looking at the schematics the board should work with direct current as well as with alternating, right? If yes, a comment would be good that OLD transformators should NOT be used as the direction switch done with old transformators can go up to 32V and from looking at your wiki your decoder is "only" save up to 25V or am I missing something?
The decoder as such works with both AC and DC voltage, but pure DC voltage or e.g. 50Hz AC voltage from a Märklin transformer is of little use because of course no information (e.g. driving commands) can be transmitted. The physical properties of the DCC signal are explained quite well here in German. As far as the maximum input voltages are concerned, the motor driver is the limiting factor. The absolute maximum voltage on the track should not exceed 27V in terms of amplitude, since the motor driver has an absolute maximum input voltage of 26V, but the bridge rectifier still has a drop of approx. 1V. You also have to keep the maximum capacitor voltage in mind. With the 10uF capacitors I suggested, the maximum voltage is 25V.
okay, silly me, thanks for the clarification. still a lot to learn with all the new stuff (at least for me). thanks!
small hints for documentation, the pico-sdk is moved to a different location: https://github.com/raspberrypi/pico-setup-windows and the probe-utility is also moved to an own space where already compiled binaries can be downloaded: https://github.com/raspberrypi/picoprobe/releases/tag/picoprobe-cmsis-v1.02
another update: openocd does not need anymore picoprobe.cfg: https://forums.raspberrypi.com/viewtopic.php?t=348242
Thanks for the hints regarding documentation, I updated 2 of the 3 things you mentioned. Did you manage to flash your hardware? And if so, which openocd command did you use? The getting started guide seems to mention "openocd -f interface/cmsis-dap.cfg -c "adapter speed 5000" -f target/rp2040.cfg -s tcl" on page 68, can you confirm wether or not that is correct? Unfortunately i cannot try it myself at the moment.
I used "openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "program RP2040-decoder.elf verify reset exit"" and programming and verify SEEMS to work (reported back successful). But currently I can't test the decoder as some basic stuff is still missing (I'm fighting with ArduinoIDE for the dccex command station, but that's not related to this project)
Okay, I've got my missing components, but so far no luck with getting it to work. How can I read the debug-uart output from the decoder? Is it save to connect the tracks AND the serial wire debug interface to find out what/if the decoder is doing something or if it's missing informations because my setup if faulty (for background: when I connected the motor the first time at the first startup the train moved, but the motor driver ic got really hot, not sure why. and now after a day where I checked the motor and other stuff nothing is happening, not sure if the chip got too hot and died, if power is missing or what is going on)
I presume you successfully programmed the decoder via openocd? From your description it is kind of hard to tell what's happening. First of all it would be helpful to check the +V and 3V3 voltages. You can also connect a relatively low resistance resistor as a load for the motor driver and try to read CVs on the programming track (The resistor is needed as it provides an acknowledgment for the central as to which bits are set). Another thing you can try, is to check the GPIO by mapping one of the functions to correspond with one GPIO pin via the table "CV.h".
Regarding the uart output, that wouldn't be of much use as nothing really gets printed to the console. What would be useful of course is to use serial wire debug (SWD) to step through the code in order to find out what's happening. Wether it is safe to connect both SWD and supply power using the tracks depends on your setup. What i mean by that is, you would have to keep in mind that if for example you are using the dccex command station and it is connected to your PC that is also connected to your programmer all of those ground potentials are tied together. If you now tie GND of the decoder together with the GND potential of your programmer / dcc-ex / PC you are effectively bridging one of the diodes in the bridge rectifier as the GND potential of the Decoder is actually one diode voltage drop (~0.7V) lower than the GND potential of your programmer / dcc-ex / PC GND. Although i would not recommend it, it should be alright in most cases you of course shouldn't supply power from both the programmer and the tracks, as in only tieing GND to GND, GPIO2 to SWCLK, GPIO3 to SWDIO and not connecting VBUS to your decoder.
what I found out today evening: I had a bad connection in the supply. Fixed it and now I have: when I power on the locomotive the wheels rotate very slow and multiple times (I expect that this is the initial measurement of the motor). Afterwards nothing happens anymore, but when I look at the output of the motor driver ic I can see that the motor is supplied with ~15.8V, but the motor does not rotate. When I now push the wheels a tiny bit they go to full power and rotate perfectly. But I can't steer the 15.8V, not sure why, changing the controller does not change the power supply voltage.
The locomotive is a really old one with 3 rotors and a permanent magnet, with the old setup without decoder pcb the locomotive worked...
Any tips or should I add debug-printfs to try to find out what is going on in the software? (I suspect it's in a strange state OR the decoder is doing something which my (old) motor doesn't like and causes this strange behaviour?). Compiling the firmware for the decoder is no problem).
Should I exchange the motor by a resistor (is 1k "relatively low"?) and what can I check to see if the decoder is working as expected, looking at the voltage on the resistor?
by the way: big thank you for helping me debugging, if I ask too dumb questions give me a hint and I will try to solve it on my own as I know that supporting open-source sw and hw is of course also work and takes time! I would offer to try to help you add some documentation and hints what I (as a total hw noob) find helpful in the wiki...
Thanks for the offer regarding the wiki, I think that's a great idea and I'll give you access to the wiki.
"Afterwards nothing happens anymore, but when I look at the output of the motor driver ic I can see that the motor is supplied with ~15.8V, but the motor does not rotate. When I now push the wheels a tiny bit they go to full power and rotate perfectly. But I can't steer the 15.8V, not sure why, changing the controller does not change the power supply
voltage."
This probably happens because the base PWM level calibration is set too low (maybe due to issues in the first calibration), the background being that the I component of the controller runs very high and is relatively sluggish. You can try two things:
- Set CV_176, CV_177, CV_178, CV_179 to "0" to schedule a new calibration
- Significantly lower the variables CV_52 & CV_53 and observe whether something changes in the behavior.
Note: When writing CV's, there doesn't need to be a low impedance load on the motor inputs, the CV's are still written but not confirmed. Only reading CV's requires a load at the motor input, which is why I pointed out last time that a low-impedance resistor should be connected if necessary. The confirmation or reading takes place via a current impulse emanating from the locomotive, this current impulse must exceed a certain threshold value (described here in German.) With a current threshold of 60mA and a voltage of 15V, this results in a maximum resistance of 250 ohms. However, it is advisable to choose an even lower resistance value in order to safely exceed the threshold. Alternatively, of course, the motor itself can also serve as a low-impedance load, and since this is apparently already connected anyway, that should serve the purpose.
Hi, I'd like to join the fun, but ordering assembled PCBAs from China is a bit overwhelming for me. Would anyone be willing to sell a few in Germany?
Hi there! How many decoders do you want to have? But honestly with the files provided by Gabriel in this thread it's really a no-brainer to order from jlcpcb (and be warned, up to now I have no proof that my order works as expected!). And: we should find a forum to discuss things like these as this should not belong to the errors from the project. I would propose Stummiforum?
You are right, let's use https://github.com/gab-k/RP2040-Decoder/discussions 👍
I'm still debugging.... I've found out that if I connect the motor the dccex prints "Prog Track Power Overload: current=260 max=248". Disconneting the motor does NOT print this. Adding a 100ohm resistor between the motor connectors of the decoder also does NOT print this and reading CVs works.
Now looking at the motor I have connected three "cleaning" chokes (German: Drosseln). One between the connectors of the motor (it's the original one from Märklin) and two between the motor connectors and the decoder (they should be 3.3 uH each, but looking at the colors it might be more 1.1uH each). Are these chokes needed? Can I test without them? (I've read somewhere that they are needed to protect the decoder?). Can these chokes make trouble?
I'm still debugging.... I've found out that if I connect the motor the dccex prints "Prog Track Power Overload: current=260 max=248". Disconneting the motor does NOT print this. Adding a 100ohm resistor between the motor connectors of the decoder also does NOT print this and reading CVs works.
This is pretty much the intended behaviour as far as i remember the dcc-ex programming track is current limited to ~250 mA. What seems weird to me however is, that it should still be able to read the CVs no matter the overcurrent situation as far as i remember.
Now looking at the motor I have connected three "cleaning" chokes (German: Drosseln). One between the connectors of the motor (it's the original one from Märklin) and two between the motor connectors and the decoder (they should be 3.3 uH each, but looking at the colors it might be more 1.1uH each). Are these chokes needed? Can I test without them? (I've read somewhere that they are needed to protect the decoder?). Can these chokes make trouble?
The chokes are for radio interference suppression and should not make any trouble. What do you mean by, between the connectors of the motor? Normally there probably is capacitor in parallel with the motor. A schematic would be helpful here. Also you can try temporarily removing the chokes it is not a hazard to the decoder.
how can I activate the serial console for debugging? is it correct that I need to enable uart output and connect gpio0/1 for uart output?
I'm a bit unsure as I've found this in the cmake-file:
enable usb output, disable uart output
pico_enable_stdio_usb(RP2040-Decoder 1)
pico_enable_stdio_uart(RP2040-Decoder 1)
my understanding is that uart is always enabled as well as usb (and despite the comment). but that would mean that gpio0/1 is NOT used for connection of the decoder to some LEDs or some other lighter load?
is it easier to connect usb for debugging or did you use uart with gpio0/1?
https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf
Appendix A should answer your questions, "Picoprobe Wiring" in particular.
When it comes to using gpio0/1 as gpio you are correct, uart needs to be disabled for that.
okay, when disabling the decoder-usage of gpio0/1, adding printfs and soldering the uart to my "picodebug" board I can receive debug-messages and found out what is happening: the measurement at least with my motor seems to not work. when I force a re-measurement I can see that the measurement always returns ~10 with the loop-condition never getting more than 5.
measurement = measure(CV_ARRAY_FLASH[60], CV_ARRAY_FLASH[61], CV_ARRAY_FLASH[62], CV_ARRAY_FLASH[63], direction); LOG(1, "level %d measurement %f loop-cond: %f\n", level, measurement, measurement-(float)CV_ARRAY_FLASH[171]); if (level > max_level) { // Abort measurement and write default value of 0 to flash LOG(1, "measure_base_pwm: abort measurement and return 0\n"); return 0; } } while((measurement - (float)CV_ARRAY_FLASH[171]) < 5.0f); LOG(1, "level_arr[%d] = %f\n", i, level);
results in this:
new adc offset CV[171] (9.949064): (uint8_t)10
found cv[175] equals to 0, forward direction
iteration 0: maxlevel 5000 level 250
level 260 measurement 10.000000 loop-cond: 0.000000
level 270 measurement 10.714286 loop-cond: 0.714286
level 280 measurement 10.814285 loop-cond: 0.814285
level 290 measurement 9.428572 loop-cond: -0.571428
level 300 measurement 10.685715 loop-cond: 0.685715
level 310 measurement 9.600000 loop-cond: -0.400000
level 320 measurement 9.628572 loop-cond: -0.371428
level 330 measurement 10.942857 loop-cond: 0.942857
...
level 4880 measurement 10.728572 loop-cond: 0.728572
level 4890 measurement 10.757143 loop-cond: 0.757143
level 4900 measurement 10.942857 loop-cond: 0.942857
level 4910 measurement 10.400000 loop-cond: 0.400000
level 4920 measurement 10.757143 loop-cond: 0.757143
level 4930 measurement 9.700000 loop-cond: -0.300000
level 4940 measurement 10.571428 loop-cond: 0.571428
level 4950 measurement 9.614285 loop-cond: -0.385715
level 4960 measurement 9.485714 loop-cond: -0.514286
level 4970 measurement 10.314285 loop-cond: 0.314285
level 4980 measurement 10.814285 loop-cond: 0.814285
level 4990 measurement 9.685715 loop-cond: -0.314285
level 5000 measurement 10.342857 loop-cond: 0.342857
level 5010 measurement 10.414286 loop-cond: 0.414286
measure_base_pwm: abort measurement and return 0
found cv[177] equals to 0, reverse direction
iteration 0: maxlevel 5000 level 250
level 260 measurement 10.000000 loop-cond: 0.000000
level 270 measurement 10.400000 loop-cond: 0.400000
level 280 measurement 10.285714 loop-cond: 0.285714
should the motor rotate during this measurement at least a bit? mine is not moving at all during this process..... and should core 1 run during these measurements (it's not running in my case)
(btw I will create a page "how to debug" and if you like I can make a pull request with the debugging info I've added, you can see my changes in my fork).
Edit: or wait, is it a good thing that the measurement returns with 0? (I assumed it's an abort, but could also be that the adc works correctly and don't need adjustment?)
and btw you let the cmakefile (and hence the startupcode) enable uart and reconfigure the gpios later, cleaner would be to disable uart debug output in the production builds completely to remove some more unneeded dependencies...
okay, when disabling the decoder-usage of gpio0/1, adding printfs and soldering the uart to my "picodebug" board I can receive debug-messages and found out what is happening
In hindsight i should have recommended SWD Debugging to you, as you wouldnt even have to solder anything and could just step through the program using breakpoints and stop execution, continuing and so forth, it has many advantages in contrast to just using printf. If you want to read up on how to do that, refer to Chapter 6 and 7 in the Getting started with Pi Pico PDF.
should the motor rotate during this measurement at least a bit? mine is not moving at all during this process.....
Yes it should slightly rotate, can you try with another motor?
and should core 1 run during these measurements (it's not running in my case)
That should be correct as the measurement is called from cv_setup_check() which gets called from main() i.e. core0
Edit: or wait, is it a good thing that the measurement returns with 0? (I assumed it's an abort, but could also be that the adc works correctly and don't need adjustment?)
Thats most certainly not a good thing usually this value is depending on the motor somewhere in the 500 to 3500 range.
and btw you let the cmakefile (and hence the startupcode) enable uart and reconfigure the gpios later, cleaner would be to disable uart debug output in the production builds completely to remove some more unneeded dependencies...
That is correct.
printf debugging is fine, I knew about SWD debugging but for now I prefer printfs...
I don't have another motor I can test with, at least no one from a locomotive... can I somehow test if the motor is working by desoldering the decoder and applying dc directly to the motor?
when I do the measurements and apply manual rotation to the motor the measurements do NOT change, is that normal?
printf debugging is fine, I knew about SWD debugging but for now I prefer printfs...
However you prefer, keep in mind the time it takes to execute printf regarding time critical tasks like the motor controller. In this case there shouldn't be a problem with that.
I don't have another motor I can test with, at least no one from a locomotive... can I somehow test if the motor is working by desoldering the decoder and applying dc directly to the motor?
Yes, that's a good idea.
when I do the measurements and apply manual rotation to the motor the measurements do NOT change, is that normal?
Whilst that will generate a voltage, it might not be in the moment the ADC samples it.
does it make sense to replace the motor by a 100ohm resistor and do the measurements to find out if that works?
and in addition I plan to replace the decoder by another one, my only concern is if the first one was damaged somehow, how can I be sure that the second one is not damaged.... (of course I will apply directly the printf-version to directly see the first startup and get measurements. (does it make sense here to use the 100ohm resistor just to check if everything works as expected?)
does it make sense to replace the motor by a 100ohm resistor and do the measurements to find out if that works?
No, the measurement works by measuring the back-EMF voltage of the motor.
and in addition I plan to replace the decoder by another one, my only concern is if the first one was damaged somehow, how can I be sure that the second one is not damaged.... (of course I will apply directly the printf-version to directly see the first startup and get measurements.
I'm gonna write you a test function later, I'm on my phone ATM.
(does it make sense here to use the 100ohm resistor just to check if everything works as expected?)
Same as above, the resistor lacks physical properties, i only recommended it for testing the CV reading functionality.
Try this test function calling it somewhere about line 552 in core0.c should be fine i think. The expected ADC values should be a rather high values depending on track voltage a bit of course.
Edit: i didn't try to compile nor test this but the principle should be clear.
thanks! will try.
btw, when I appy a pure dc signal (~14V) the motor should rotate, right? it's not rotating, that means I need to order a new rotor? (what I tried, I had a very old train from ~1960, put the decoder inside and put a permanent magnet to make the motor accept dc. seems something did not work out :/ )
edit: after opening the motor, checking the rotor and closing the motor again the motor works with dc applied directly. will check more, sorry for all the mess :/
edit2: fuck, now after the motor is working the decoder is working like a charm. don't ask me what happened, but I learned a lot for sure... are you interested in my debug logging (it's compiled out when disabled, but can easily be enabled. I could clean up a bit and make a pull request if you want to have the logging stuff. I will do a wiki-page how to debug.
edit3: I'm really sorry for all the confusion, but big thank you for helping me all the time! I feel really dump, even when I still don't know why it's now working and did not work on the first try.
edit: after opening the motor, checking the rotor and closing the motor again the motor works with dc applied directly. will check more, sorry for all the mess :/
Don't worry
are you interested in my debug logging (it's compiled out when disabled, but can easily be enabled. I could clean up a bit and make a pull request if you want to have the logging stuff. I will do a wiki-page how to debug.
Yes that is a very good idea.
Can i contact you some way via email, perhaps the one on your website?
you're more than welcome to write an email: http://www.unseen-academy.de/legal.html german is fine ;)
will prepare some more commits with documentation about debugging...
have you written an email? I have received nothing so far?
what I found out today evening: I had a bad connection in the supply. Fixed it and now I have: when I power on the locomotive the wheels rotate very slow and multiple times (I expect that this is the initial measurement of the motor). Afterwards nothing happens anymore, but when I look at the output of the motor driver ic I can see that the motor is supplied with ~15.8V, but the motor does not rotate. When I now push the wheels a tiny bit they go to full power and rotate perfectly. But I can't steer the 15.8V, not sure why, changing the controller does not change the power supply voltage.
The locomotive is a really old one with 3 rotors and a permanent magnet, with the old setup without decoder pcb the locomotive worked...
Hi @questor , I am also having the problem with motor keep turning with 15.8V and it is not controlled by the DCC command station. I am using the ESU decoder tester PCB (with a motor and some lights) and I could verify that the motor is in good condition. Do you have any thoughts on this?
I've an open pull-request with logging enabled in the decoder, you have to compile my branch, attach the flashing-rp2040-board without the VCC from the flashing-board (it's powered by the tracks, for reference from Gabriel: "Wether it is safe to connect both SWD and supply power using the tracks depends on your setup. What i mean by that is, you would have to keep in mind that if for example you are using the dccex command station and it is connected to your PC that is also connected to your programmer all of those ground potentials are tied together. If you now tie GND of the decoder together with the GND potential of your programmer / dcc-ex / PC you are effectively bridging one of the diodes in the bridge rectifier as the GND potential of the Decoder is actually one diode voltage drop (~0.7V) lower than the GND potential of your programmer / dcc-ex / PC GND. Although i would not recommend it, it should be alright in most cases you of course shouldn't supply power from both the programmer and the tracks, as in only tieing GND to GND, GPIO2 to SWCLK, GPIO3 to SWDIO and not connecting VBUS to your decoder.").
I don't fully understand the issue, but it worked for me to connect the tracks AND the flashing-board without VBUS and I was able to receive debug printfs I've added (you have to enable compile-time switches in my repo to enable printfs!).
In the end I think what happened on my side: I have issues with the motor which resulted in corrupt measurements with the result of a really strange behaving decoder.
Another tip: to check basic connectivity between your decoder and the command station you can desolder the motor and replace it by a resistor of ~100ohms to be able to check the connection between commandstation and the decoder (reading and writing CVs should work!).