Hey all, just a little heads up on a discovery. It appears that the mega clones do not use the same address for the on board usb port. Just looked at 2 clones and there were 2 different addresses for the usb port. One was 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter and the other was 2341:0042 Arduino SA Mega 2560 R3 (CDC ACM).
I think that is the one I was thinking of, it covers a number of options and detects the chip type on the LCD if possible.
@Jack Regan are you saying that you think the Pi just is not communicating to the Mega via the serial port? Those numbers are just the manufacturer ID and the product ID. So that is what I would expect to see for one of those ch341 type UARTS. I have a lot of different microcontrollers from China that use the same chip. Is JMRI setting up a rule based on the Vendor ID? Or is it just that the Pi is not registering that device to ttyUSB0 or whatever port it is? I have an Elegoo Mega and it worked out of the box. I'll try the WiFi Mega and see what it does.
When Steve had me do a lsusb search for the ports that's when he saw the different address points for serial 0. Apparently engine driver connects using the address. He modified the panel pro auto id file and it was able to connect. So as it stands, engine driver installed on a kindle fire is connecting to a Raspberry Pi with JMRI which is connected to a Mega2560 with DCCppEx as the base station. That just happened tonight. I have not verified operation yet. If that is working then I just need to figure out the data structure of the turnouts. If I can get the ID number of the turnout when it's selected then I can send that to a turnout control system that would not need DCC++.
Okie Dokie, I now have a DCC++ system. Have not tested it because I have now equipment but what to leard what was involved. Using a Raspberry Pi as the access point and to handle JMRI. Steve Todd released a new image file that takes care of the close issue I found. But even if the port is not automatically detected, it can be added manually. I have the DCCppEX sketch on a mega2560 and modified a L298N board for the engines and tracks. Here's a picture.
As far as I can tell, all of the Chinese boards use one or the other of these chips. For example, the Elegoo Mega uses 2341 and the WiFi Mega uses 1a86. There is a database here, so it is easy to see what manufacturer are linked to what vendor ID and then what product ID subcategory they are: https://the-sz.com/products/usbid/index.php?v=2341&p=&n= That link is already set to search for "2341" so you can see all the products using that code for Arduino.
So for those waiting for an update on the installer here it is, I would like to present Base Station Installer 2.0. In this version it is now officially CROSS PLATFORM. This update includes builds for Mac Linux and even the Raspberry Pi. Installing DCC++ or DCC EX has never been easier. https://github.com/DCC-EX/BaseStation-Installer/releases/tag/v2.0
Dex I used it and it seems fine, thanks. The first run it only showed one serial port (com 4) and it wasn't the correct one as it didn't load. I went to device manager (using win10) and it showed two serial ports (4 and 5) with the arduino on 5. I ran the installer again and it came up on 4 but then with the dropdown I could now see 5 and chose it and everything worked fine. Plugged it into the Pi and the test track and train ran fine. Haven't tried decoderpro on the program track at this point. Also the Com problem happened as I was late for lunch and then ran it again an hour later so maybe there wasn't a com problem the first run. Might of been me in a hurry but I remember the dropdown only showing 4 then but maybe I'm wrong. I was also a little confused on which file to initially download as I didn't scroll all the way down the page and didn't see the other files below the 'run on mac' and 'Linux' sections. Maybe a standalone section for windows also and an explanation of using BaseStationInstaller-win-x64.zip82 woo woo woo BaseStationInstaller-win-x86.zip78.4 woo woo woo I though the first section. BaseStation Installer dexslab released this 5 hours ago would take me to the right place but clicking on it doesn't. Anyway great work as usual, Sumner
Now that I have my JMRI running without issues I have succesfully compiled and uploaded your sketch to my MEGA. Can confirm it at least runs my trains without problems. My Railcom detector does say Railcom byte: 255 all of the time, but I think this is due to not having an isolated section on my track yet, along with some other shortcomings in the wiring. So that's something I'll add this week. For now, maybe you could provide some feedback on whether my method is compliant with what's required. I have added the detector sketch (very basic) to my PCB repo, so someone might aid in verifying the methods used. https://github.com/dikkedimi/RailcomDetector I'll update with the new results once I fix my wiring. Also, am I correct in assuming we can mux/demux the railcom blocks by having window detectors for each section and then switching the UART read to the appropriate block?
It is close, the raw bytes you read in from Serial need to be decoded using the 4/8 scheme defined in the spec. isolated sections are not mandatory, what you have without isolation is a global detector.
Dex, Thanks for provided on the new Base Station Installer 2.0. I did three tests with Win8 to connect and compile on an Wemos Mega Wifi 2560 + ESP8266. First with only Mega 2560 dip settings, a second with Mega & ESP dip settings and a third with 1-4 dip settings on. Successful on Mega tests 1 & 3 they seems to have worked just fine, Great Job! So I'm approaching this as a "new user" and followed the boards dip recommendation and the instructions on Readme.md. Test1: My Mega 2560 Test was set as follows: dip switches 3 & 4 On, others off Selected; DCC++EX Mega Arduino Motor Shield Comm 16 {vid 1A86 pid 7523 ch340 } Uploaded and Serial Monitor tested just Fine Test2: My Mega 2560 <--> ESP8266 Test was set as follows: dip switches 1 & 2 On, others off Selected; DCC++EX Mega Arduino Motor Shield Comm 16 {vid 1A86 pid 7523 ch340 } Appears to have Uploaded Fine but No Response from the Serial Monitor commands. Can we add a choice for Arduino UNo or MEGA Wifi ESP8266 boards? I'll need to read up of Mega Wifi and make some more edits to the sketch and recompile. Test3: My USB <-> Mega 2560 <--> ESP8266 Test was set as follows: dip switches 1, 2 3 4 On, others off Selected; DCC++EX Mega Arduino Motor Shield Comm 16 {vid 1A86 pid 7523 ch340 } Appears to have Uploaded Fine and the Serial Monitor commands respond just Fine.. Observations on the UI feed back; While compiling prompting the user with "Please Wait while we compile and Upload" When it is finished a user prompt with something like (clients 'choice' inserted) " 'DCC++ EX' has been uploaded to 'Mega 2560' " "Please close the Installer" The Installer currently leaves a copy of DCC++ within it's base folder. Could we add this to the prompt, or to the Readme.md; "The 'DCC++ EX Sketch' Folder is in 'BaseStationInstaller-win-x64' Folder." "Please feel free to move it to your User/Arduino/ Folder, then edit this sketch with your specific layouts needs and compile & upload it again" Or Move it there for them? Just food for thought on ease of use feedback. Note: I've only tested the installer and not the full functionality of the Mega ESP Wifi DCC++ implementation yet. Brilliant work. Regards, Kevin
so I read up on hamming codes, is that similar? it's the only thing I could find with google. As far as I grasp the material, the 4/8 coding is a variant? Or is it similar but different? I'm not a math buff (or maybe I am but nobody ever taught me well enough) so my matrix math isn't very strong. I found a library for 3/8 hamming codes, unfortunately there was no example, and the test routines won't compile for an arduino nano. I think it could be adapted to support the 4/8 coding. I'm having a bit of trouble with how to use the classes, mainly syntax... If someone could write up an example I'm confident I could figure out the rest. https://github.com/bkeevil/HammingSerial this is what I typed so far that will still compile.. Code: #include <Hamming.h> #include <HammingSerial.h> #include <Test_Framework.h> HammingCode Hamming; FifoBuffer FiFoBuffer; void setup() { Serial.begin(250000); } void loop() { } } yeah I know it's nothing
not likely, a listing of the 4/8 encoding can be found on page 8 of the spec (english translation). But in very basic terms, there will always be four one bits and four zero bits. There are only a handful of combinations that are valid bytes and a small number that are reserved for control codes (ACK, NACK, etc) It would be a lot easier to use a lookup table, it is 256 bytes in size and can be stored in PROGMEM as a constant.
Well this library has a lookup table too (the quick decode).. and I believe hamming codes are similar in the sense that it uses 3 out of 8 bytes to send 4 bytes of data with error correction. a certain byte sequence is only valid if the parity bits are set correctly. So it seems it's a more beefed up variant. I can at the least steal some insights from it Decoding the bytes should also be similar. I need to load the serial data into a buffer, when that buffer is full analyze the sequence and then do a lookup, pop, push new data into the buffer and repeat. obviously some interpretation as well. Since parity doesn't need to be checked (i assume), this could be even simpler than this library facilitates. Main problem I have is defining the serial en streaming it into the buffer. Sure I'll get there after some reading and interpreting functions.
you don't really need to buffer it, you can receive one byte at a time and use it against a lookup table that is pre-defined and pass the decoded byte up the stack to whoever needs the data. Keep in mind you are working with up to six bytes of data and code speed is critical, it must completely receive all six bytes within ~487usec so that the DCC signal is not impacted by the cut-out.
See the code I wrote up for my commandstation library here (Railcom.cpp and Railcom.h) https://github.com/DCC-EX/CommandStation/tree/master/src/DCC It's a bit of a mess at the moment but it works for CV reads on the main.
Hello, please forgive me for asking what might be a really stupid question, the last time I had model trains I was 10 years old and now I'm over 50 so times they have a changed, IF I understand things correctly having read the last 32 pages. DCC++EX will allow you to listen for the ack signal sent out by the DCC decoders in Locos which (again if I understand correctly) you can use to indicate on your JMRI track plan which section of track your loco is in, but this won't actually tell you if the track is occupied by something without a decoder, for that you need a current sensor. So for each section of track will I need a current sensor to tell me if the sector is occupied and some sort of Opto Isolated feed to an Arduino to be able to read the ack signal ? Can I then use a single arduino to monitor multiple sectors and if so how many ? assuming a current detector and a dcc feed per sector Or is this really not a DCC++EX question and should it in fact be a CMRI module ?
ROFL on slugging through all 32 pages of this We are going to move things around a bit now that we have had such a discussion here. We are also using Discord and filling up their servers now with all our collaboration on everything coming so that this can be more for general discussion. You are close. The ACK detection is only for programming the loco on the Programming (Service) track. That is how we can read CVs and such. You would need occupancy detectors to know what section of track your loco just passed connected directly to the DCC++ Control Station. So think of the DCC signal we generate on the rails as one-way communication to whatever device you are controlling. There are 2 ways to handle accessories and block detection and all the rest. First, you can control accessories (like turnouts, lights, whatever) in the JMRI software or anything that acts as a front end to DCC++ Classic or EX. You can control these just like a loco if you connect them to the rails. Again, one way communication. JMRI sends the codes to our Control Station. You also have a lot of pins you can connect things to on an Arduino and you can read inputs and outputs. So you are only limited by the spare GPIO pins on the Arduino. This can be bi-directional since you aren't using the rails, you are connecting directly to the Arduino. There are a lot more pins on a Mega, so we recommend that board if you have a lot of things to monitor. See here: https://www.jmri.org/help/en/html/hardware/dccpp/Sensors.shtml But the second way is to have another bus to handle these things such as CMRI, LCC or anything else you want. Some people like a "node" type bus that you send commands to and IT handles your accessories. It depends on the usual things, the size of your layout, what you are trying to accomplish, and your budget.
