Hi Steve, I'm guessing you mean Dave B. has not been very active. I think a few of you guys are having issues with the said modules. I've no experience with that technology unfortunately (enough on getting WiFi down pat ). On my throttle. Well the hardware and software are proven concept - save for putting the software on the new node mcu chip and giving it a good workout. What the project needs, is a really nice enclosure. I've looked all over the Chinese markets and nothing fits the bill. I'm always on the look out for a cheap product that I could modify. Failing that, I'll look into doing a 3d modelling crash course and eventually get something 3d printed. At least folks will then have that option and the file will just be a digital copy which you could get printed locally. Other than that the display interface needs a nice upmarket look designing for it, but again that's just some more time doing it all digitally on the PC. I guess you saw the picture over on the 'Throttles' thread. How's the WT shield holding out ? Steve
Steve Yes, got Dave and Gregg confused ....... would love to see something on the components your using for the throttle (even though still in progress) I haven't run trains in a while, loving all the electronic funs ..... WT shield doing fine ........ Node MCU shield sitting on the bench getting lonely .... scheduled for after I get my HC12s to communicate. Steve F
I feel sorry to contribute to hijacking of this thread which topic originally was "Introducing DCC++..." but the Wang Tongze WiFi shield V1.0 was not discussed in other thread than this one... I purchased the shield in the eBay shop linked in this thread and was disapointed by its malfunction so much that I took my heatgun and desoldered the ESP-12E module to do better analysis of the shield layout and signals. Later I desoldered as well as the components expectedly doing TX/RX signal level conversion between 3.3V and 5V (see the picture). I found out that while the module itself works OK as expected, the PCB of the signal level conversion is designed totally wrong so that the shield could NEVER work correctly with Arduino. Money thown down the drain. Correction: the PCB would be probably OK for a bidirectional level shifting convertor using DMOS N-channel transistors BSS138 (see attached picture), but hardly can work with the general purpose NPN transistors S8050 (marked J3Y) which actually were found on the shield.
@Jirka, Thanks for your observations, however while I myself had some issues programming the shield via the the female headers 0 and 1 at 5v logic it worked at 3.3 volts. And also at 5v via the Debug port. Of course I suspected the same as you in that the logic level circuitry is at fault. But once the shield is programmed, it works without issue, at least mine does anyway. I've recently acquired a level shift module using similar components, so I'll do further checks on shield component configuration now this is brought to light. Regards Steve.
Hello, Gregg and all the others, this project is AWESOME! I have been running my model railway in the analogous way up to now, but since about a week I am infected with the digital virus due to the possibilities of DCC++. Within two hours I was able to bring the base station up and running without any issues using an Arduino Uno and a regular Arduino Motor Shield. Since that point in time, I have been chewing on the Java code of the Controller software. I was able to get my head around most of the code, and was able to customize it already for my locos and program them using the Controller. The part of code that is most confusing to me is the AutoPilot routine. I understand its purpose and the general way it operates; but to find the pattern of operation within the code is currently still too difficult for me. I think of the AutoPilot as some sort of state machine (which is highly adapted to a specific railroad layout), that gets triggered by "some" sensor signals and controls turnouts and engines. I assume the core procedure is the "process" method (line 268 in dSensors.pde). But the whole routine is unfortunately very little commented. So to start the questioning, I'd be curious to know what the purpose of the variable "s" and the variable "phase" is, maybe I understand by this more the way this works.
Hi everyone, I'm new to the Trainboard. I joined mostly because I want to use and improve DCC++. I'm impressed which what I've discovered so far, but the code could use some work here and there which I would like to sync with the original author. Things like repeating the function commands (as requested by the NMRA RP) and slimming down the RAM footprint to have more space for "registers"/"slots". I'm new to Arduino programming, but have been programming in C for a very long time. I've not been sucessful in contacting Gregg on his Github Email. Regards, Harald.
I am not sure what happened to Gregg. the last post I found in this thread is here: http://www.trainboard.com/highball/...ation-and-interface.84800/page-68#post-979603 Welcome to the forum. I too came here for DCC++. I started out with the thought of improving DCC++, but I soon found that it works, so "if it ain't broke, why fix it". I have made a few alterations for personal preferences. mainly, the protocol timing is important, so I don't want to mess with too much. Currently I am waiting for some parts to be delivered, then I will have a working DCC++ setup, with a much higher main track current capacity. I have found this forum to be full of very good information, and I hope to expand my interest in DCC++, and broaden my knowledge of trains, and model trains. ~Travis
The things I want to fix (as of what I can think of today): * Refresh function commands (as the trottle commands) * Remove the requiremet to manage a slot number (which means you always use the cab number to add and to remove cabs from the internal table) * Make parts of the code conditional to free RAM (2k of the UNO does limit the refresh table to be around 30 entries unless you make other features like sensors conditional) * Make the code more slim in respect to RAM usage (replace for example int (2 bytes) with byte or pointers (2 bytes) with indexes (1 byte)). * Send commands to the "long" adress range but to adresses below 128 (I know this sounds strange but is needed for decoders programmed by LENZ central units) Harald.
I look at this piece of RegisterList::LoadPacket() Code: buf[0]=0xFF; // first 8 bytes of 22-byte preamble buf[1]=0xFF; // second 8 bytes of 22-byte preamble buf[2]=0xFC + bitRead(b[0],7); // last 6 bytes of 22-byte preamble + data start bit + b[0], bit 7 buf[3]=b[0]<<1; // b[0], bits 6-0 + data start bit buf[4]=b[1]; // b[1], all bits buf[5]=b[2]>>1; // b[2], bits 7-1 buf[6]=b[2]<<7; // b[2] Why is there a 22 bit (_bit_ not _byte_ as in the comment) instead of 14 bit preamble? In my opinion the end "one" bit of the packet is missing which is compensated by the fact that the next packet has 8 unnecessary "one" preamble bits. So I'd cut one byte at the start and add one bit at the end unless there is a reason not to do so. Harald.
when I arrived here, I had a few ambitious plans for adapting the code. but the more I read into the code, and the more I heard from other members, the more I realized on some components, if it ain't broke, does it really need to be fixed? having said that, I encourage you to modify the code to make what improvements you need, and when you have a working copy that has been tested to work, by all means share it. it will be a lot easier to bring people on board (shameless train reference) with your idea if you have a tested feature that works. Having said that, on my copy of DCC++2, I have changed the current monitoring system so that when a track overloads, it shuts down Only the affected track, and uses a CURRENT_SAMPLE_MAX for each track. a simple fix, and probably a cludgy way of doing it, but it compiles and runs, though I haven't actually tested it yet do to lack of usable track. but in theory... how exactly would you connect 30 sensors to an UNO? personally, I use a MEGA 2560. ~Travis
I meant 30 cabs which need to be refreshed, not sensors. My goal is for the UNO to be able to manage around 60 cabs, but in that case not to do anything else. If I want to read sensors or use other outputs I can use another Arduino. I just want to generate the DCC signal and do that well. Harald.
I was wondering, who is in charge of the DCC++ Github page? I have made some changes to the source, and was wondering if I may post the altered code on my Github page, with a link to the original. Mainly it is for keeping track of my own changes, but anybody can browse if they want. ~Travis
I knew Gregg started it, but I haven't seen any posts by him for a while. I guess I just assumed the torch was passed to someone else, or he is using another name. Hopefully all is well with him. ~Travis
The code is GPLed, so there is no legal problem in publishing modified versions, but it's of course best if the person who has written the original code and understands it can coordinate modifications/enhancements. And it's good to avoid double work as well. Harald.
I knew it had a GPL, I was being polite. But I am going to take the statement in the readme file, "Please feel free to download and copy any relevant code to customize your own version of DCC++ Base Station.", and I went ahead and posted my version on my Github. it may even be work somebody has already done. I don't know. I first posted the latest release (DCC++2.0) to my Github, then I swapped files for ones that I altered, so if anybody want's to view the DIFF results, feel free. my Github is: https://github.com/travisfarmer some of my other work is there too, feel free to copy code. some of the stuff is complete, some has been abandoned, but saved in case I go back to it. I didn't modify much. mostly just playing around with the current monitor portion. ~Travis
@Harald, for refreshing the active functions on all cabs, I use the cabButtons Arraylist with "cabButtons.get( ).fStatus[ ]". I can reconstruct the function messages going out to the Arduino basically copying the code of the procedure "activateFunction(boolean s)" into a new piece of code in the "draw()" routine, whereas for my case I only update the lower functions (lights and so on). To reduce the load on the Arduino, I do this only once per second. Hope this helps, otherwise feel free to ask back. Greets, Thomas.
you should have forked the base repository so you could submit a pull request But otherwise looks good!
I must admit, I am no Github pro. I started with it a few months ago, so to me, a fork is what I eat with, and a pull request is unknown to me. But thanks. ~Travis
right now I am playing around with using a couple ACS712 (hall-effect based linier current sensor) that I got off ebay a while ago. my intent is, if they are sensitive enough, then I can use any MD board, and get the same current sense readings. unfortunately, I have the 30A versions, so I don't think they will have enough sensitivity, but I think the idea may be sound. I may have to buy some with a little more sensitivity. this is what I am playing with: http://www.ebay.com/itm/121686377854 I may end up using a 5A version for the programming track, and one of the 30A versions I already have for the main track. right now it is just code and theory. tomorrow I will put something together to try it out. ~Travis
