You keep updating openmrnlite in your code, but the github version appears to have been abandoned. Do you thing that your code will ever be re-integrated into that repository? Or is there another repository that I don't see that is being updated?
I'm the primary maintainer of OpenMRN on the ESP32 so I typically run a slightly newer version of OpenMRN on the CS, many of the recent updates for OpenMRN are related to ESP-IDF v4.x+ support (WIP PR). The only piece left to be worked out is the CAN driver which needs to be rewritten to remove the usage of CanBridge and two FreeRTOS tasks which lead to priority inversion issues. I'm holding off on rewriting the driver pending ESP32-S2 support in IDF as I don't want to maintain an ESP32 and ESP32-S2 version. OpenMRN is a massively cross-platform LCC implementation which has been trimmed down to bare essentials and released as OpenMRNLite which is listed in the Arduino IDE Library manager. OpenMRNLite is very overdue for a new release, especially since it now supports the Arduino-STM32 platform. I will raise this with the others in the OpenMRN team and see where it goes.
It's not a waste as the current driver is less than ideal even on the esp32. I've got a partial rewrite but haven't finished or tested it fully. For the CS I've got a major update on the PCB, many of the components are shifting to SMD technology and as a result there will be more functionality available and less manual assembly as almost all components will come pre-soldered! In addition the RailCom detector is being extended to support receiving RailCom feedback from boosters via the LCC interface, this is another area that was not clear previously. I'm expecting a couple parts to arrive in a couple days from Pololu (test supplies mostly) and will be finalizing the updates to the PCB once testing completes. This will also entail fixing a couple issues that were reported in v1.5.0-alpha-1 related to the prog track. Sent from my ONEPLUS A5010 using Tapatalk
I know almost nothing about railcom. I just spend an hour looking but still don't know enough. It appears the boosters I see either support USB or Omninet (sp?). So does the CS support railcom (or is that even a meaningful question)? And are boosters with detection CAN bus LCC connected? If you have a pointer to a webpage I would be glad to read that instead. I Googled railcomplus and read most everything.
RailCom is a mechanism for DCC Decoders to send data across the track, similar to how they send an ACK pulse on the PROG track except this is on OPS. There are two distinct feedback channels defined by the RailCom specification: channel 1 (occupancy data) and channel 2 (response data). There are some discussions about extending the functionality further but I haven't seen the details yet. I don't know of any boosters that retransmit the RailCom feedback in a defined cross-vendor manner. There is a draft standard being worked on which will define a cross-vendor approach and there is already at least one commercial vendor who will be supporting the draft outside of ESP32 CS. Yes, it does support it today but there is a bit of extra circuitry that is required to receive the feedback data. Yes, that is the primary interface for boosters and RailCom feedback from them. However, there is nothing to prevent connecting a booster to the OPS track outputs and run it from there without having RailCom feedback. (Note that this may have other unintended side effects) RCN-217 is likely the best source for details on RailCom, it is available in German and English here: https://github.com/nmradcc/documents/tree/S9.3.2-draft/standards/drafts The Power Station Interface specification is being reworked and a Feedback specification is being documented here: https://github.com/nmradcc/documents/tree/bakerstu-S-9.1.2-drafts/drafts
Thank you, I read all of the documents you suggested. I understand more of it but not all. I had to go back to my EE degree I have not used in 50 years to compute some voltage and current values (I made my living writing low level drivers for things like storage subsystems). I wondered what would happen if there were a lot of locomotives at the far end of the 2.2 volt rail drop. And what the back emf would look like. And I failed badly. 488uS is really a long time for lots of power stuff. But my back EMF knowledge as left the room. So I computed this decoder https://model-railroad-hobbyist.com/node/39306 driving a 12 volt motor a 2 amps. And the 22uF capacitor will become a basic dead short in that time. (diode drop into .06 volts if I did my math right). An that close to the source is in parallel with the 1.8 ohm detector in series with 70 ohms of track (2.2V at .030ma max). I trust German engineering more that my math. So I guess I just believe that it all works. But with static decoders drawing amps and lighted cars and lots of locomotives there is lots of stuff competing for the 20ma available between the 30 produced and the 10 needed but the detector.
It is an interesting concept to have the rails go dead for nearly 5 bits of the preamble. I can't say I fully understand all of the electrical side of it either.
I looked at your circuits. Very nice. Two quick questions. What does RAIDCOM-DIR tell you? And what do Q6 and Q8 do? I assume it must limit the voltage across the diodes, but then there are D2 and D3 that do that for the detector.
Oops, q6 and q8 limit the voltage across the resisters and that is to limit the dissipation. I wrote diodes incorrectly. I have never seen parts like q6 and q8. Interesting.
Thanks, the circuit came from one of the LCC devs and is in use in another commercial product. Q6 and Q8 detect a short condition and drive the railcom-enable-gate signal to GND. They are a pre-biased NPN (47k on B input). In the latest schematic I'm working from I've dropped the DTC143 in favor of MMBT3904 with the bias resistor added (jlcpcb lists the DTC143 as an extended part which incurs a $3 fee up front to use it. D2 and D3 are not populated by default. They are more of a test point in the circuit now. The railcom-dir output is used to detect orientation of the loco on the rails. It is currently not being used though, I plan on having it used at some point in the future though Sent from my ONEPLUS A5010 using Tapatalk
I see what Q6 and Q8 do now. If too much current is drawn the short line is activated. However that will only last a short period of time as a short will dump 15V/4.8 ohms * 15V of power into those small resistors. I assumed, incorrectly that the transistors were to limit the max voltage to .5 volts or so. That would limit the power to .5**2/4.8. OF course the only way that happens is if power comes in from another power district or there is a programming bug that has OPS active with RAILCOM-GATE-EN also active.
Right, it will disable the FETs and in turn disable the short condition unless there is a real issue in the track. The code will disable the ops-en signal prior to enabling railcom-en. So that should prevent both from being active but never know. Sent from my ONEPLUS A5010 using Tapatalk
I wonder too, what has not been thought of with regard to the magic 488 microseconds. Who knows that is attached to the track? But by shorting the track and creating a current loop, with a very low resistance detector, you just have the transients to deal with. I've also wondered about keep alive caps and any other unintended consequences. You could try to use zero-constant time value calculations to actually do the math of a worst case scenario, I suppose. This would have made a great problem for my transient analysis class in college. I hated the math and the "equivalent circuits", but I did love the creative problems. My prof gave us a circuit for a stereo and you had to do the math for what happens when you turn the power on and off and on again. Who knew You could hear the laughs and "Whoah!" as each person worked out the solution. The lesson learned was: bad design could multiply power exponentially and basically throw a lightning bolt through the whole thing in a split second. Which of course immediately had me experimenting with these: and making capacitors out of sewer pipe, aluminum foil, insulating material and oil for a tesla coil. More power!
Didn't have a chance to get to it for a while. However, it is working flawlessly with "a79afd1" (v1.5.0-alpha2), thank you very much . I am still unable to connect to S88 as any new entry through the web ui there doesn't stay (but it could be that it behaves like that in case the HW is not connected correctly which could also be the case here) but that's the least important thing as the basic operation works.
Can you check the serial console for any errors? I suspect it is throwing an error and rejecting the attempt to create an entry. I'm also thinking this may be a feature that is better suited to compile time configuration rather than runtime so that additional validations can be made up front.
I wish I could easily say but whenever I have connected ESP to my PC I was getting Code: [WiFi] Connection failed, reconnecting to SSID: XXXXX and therefore I was not able to load the web UI to try anything. Trying to build post v1.5.0 Alpha 2, the latest at this time: d51586b, I can't unfortunately build it because of this: Code: ../components/GPIO/S88Sensors.cpp:306:23: error: 'StringPrintf' was not declared in this scope Anyway, this is really weird, no idea why connecting the ESP to my PC via USB breaks network stuff. Here is the log: Code: [WiFi] Configuring Station (SSID: XXXXX) [WiFi] Starting WiFi stack [WiFi] Setting ESP32 hostname to "esp32cs_50101013f00". [WiFi] MAC Address: 30:ae:a4:75:69:d4 [DHCP] Starting DHCP Client. [WiFi] Station started, attempting to connect to SSID: XXXXX. [SoftAP] MAC Address: 30:ae:a4:75:69:d5 [SoftAP] Setting ESP32 hostname to "esp32cs_50101013f00". [httpd] Starting DNS listener [httpd] Starting HTTP listener on port 80 [dnsd] Listening on port 53, fd 48, using 192.168.4.1 for local IP Listening on port 80, fd 49 [JMRI] Starting JMRI listener Listening on port 2560, fd 50 Allocating new alias 0B9 for node 050101013f00 [WiFi] Connection failed, reconnecting to SSID: XXXXX. But well, whatever. I don't think this is much too important and just as you say I suppose it would perhaps be better to config S88 stuff at compile time if that makes things easier.
Let me fix that issue on the S88 compilation failure. It likely just needs an extra include reference. As for connecting to the network, it sometimes takes it two or three connection checks before it connects (not sure why). Let's get some more debug output, edit https://www.github.com/atanisoft/ES...r/components/Configuration/LCCWiFiManager.cpp and on line 204 (just after creating the wifi manager) add: wifi_->enable_verbose_logging(); That should print out a lot more details as to why it is failing to connect. Sent from my ONEPLUS A5010 using Tapatalk
@zubozrout If you pull the latest master code it will now have an option for enabling wifi diagnostic data in the WiFi configuration section of config. I've also included the S88 fix.
