We love enthusiasm on this forum for sure, and your posts contain plenty of enthusiasm, but what I said before about calming down before you derail, I meant it. None of us are trying offend anyone and certainly not trying to offend you, but neither do we enjoy entertaining this behaviour. Just keep it real and tone it down, both in volume and frequency, or take a break from the forum for a while if you need to. We are all propheads here, we understand.
Ya know what, I will start. I love to sit in the engineers seat, blazin down the track.
I have edited prior posts, in this thread and even others. I have no problem admitting fault, even if others will not.
But someone needs to put an end to this.
Even if I disagree with you and others, I understand that forum civility is more important than me making my point.
And so the saying goes "Its nice to be important, but more important to be nice."
And to finish!
Can't you hear the captain shouting,
"Dinah, blow your horn!"
Dinah, won't you blow,
Dinah, won't you blow,
Dinah, won't you blow your horn?
Dinah, won't you blow,
Dinah, won't you blow,
Dinah, won't you blow your horn?
Someone's in the kitchen with Dinah
Someone's in the kitchen I know
Someone's in the kitchen with Dinah
Strummin' on the old banjo!
Singin' fee, fie, fiddly-i-o
Fee, fie, fiddly-i-o-o-o-o
Fee, fie, fiddly-i-o
Strummin' on the old banjo.
Although this doesn't have a parallax product in it, and I suppose I could have used a prop chip, I will post it anyway.
Feel free to make any comments about the circuit, and leave out any personal insults, or basic knowledge of electronics, "jabs", thank you.
ITS AN AMBUSH!
Here is an EOT that I am working on, dcc friendly.
Gotta have a light for that caboose, so you know if your cars are still attached to your engine at night.
I replaced the wheels in the caboose with LGB #67403 wheels with electrical pickups.
I probably only need 1 wheel with electrical pickups, and may use the other in another car.
You can connect the lantern to the ceiling of the caboose using double loops of bare wire,
so the lantern will give a SWING effect from movement down the track, it will even flicker as it swings, giving it a flickering lantern look.
NEAT! eh?
The lantern is a Luxeon Z 4000k Neutral White. https://www.digikey.com/product-detail/en/lumileds/LXZ1-4070/1416-1050-1-ND/3961155
I didn't choose the amber for the lantern, because the engine headlight is amber.
One could use a lower temp led, like a 2700k warm white led that is a more red white color.
Digikey dosen't stock them, but a net search might find some or other low temp 3000k or less color. https://www.digikey.com/product-detail/en/lumileds/LXZ1-2780-3/1416-1138-1-ND/4340038
Heres my looser, tedious, toy train, not worth of all the cutting edge stuff in this forum, EOT device.
Its deadbug style.
It works GREAT!
I guess the insults STAND, as per the forum mod. GREAT! I have never insulted anyone here to that degree, ever.
Thats real nice.
No really.
Time to make more tedious, looser, toy train posts. Lets see, what else can I make....
I KNOW, I can finish my lantern and post that TEDIOUS LOOSER TOY GARBAGE. YAAY!
I do know the covid stuff and lockdown is making people edgy. Calm down all of you.
You @"Clock Loop" are a long standing forum member with funny projects, so I don't bite on not having ' basic knowledge of electronics' you do have them, don't worry. And you are definitely not a looser.
@"Peter Jakacki" is normally also a very helpful person, it is just that everybodies nerves seem to get thin lately.
This forum was, is and should be in the future a exception of the bullying tenor found in a lot of other online forms of communication lately.
And yes @jonabel1971, I am looking at you too.
One should avoid taking critic or unexpected replies as 'personal injuries' and should avoid doing attacks on others.
As a regular and long time member of this forum I am astonished, appalled and disturbed by the change in manners lately in discussions, and yes @"Peter Jakacki" I can understand your reactions to @bbrien, but hell he is what? 72 or so and started a major (for him) project.
Is there really a need to type up that sawtooth post instead of just saying nothing?
Patience!
Guys and Gals, be NICE to each other, everybody has some pressure going on this year and it does not help at all to start small fights everywhere.
Do it like those steam engines and to release pressure and just whistle or whatever they do.
And YES @"Clock Loop" I am interested in your posts, even if they mention non Parallax solutions, this is or should be a technical forum for EE's and Hobbyists who do something and need or found a solution.
Anyways, PLEASE we NEED to stay calm and friendly, all of us.
After some emails back and forth, I think we are at a calm reset. After I mentioned to clockloop it was probably a phase of the moon and he looked it up an it was a New Moon yesterday! Back to our normal programming.
A NOTE ON POWER PICKUP FROM THE TRACK TO THE WHEELS. PREVENT SHOOT THROUGH. PREVENT DIRECT SHORTS FROM DIFFERENT ZONES. PREVENT REVERSE LOOP SHORTS!!!
(at least from axle to axle, very temporary shorts happen when the wheel bridges the zone isolator)
Some may think this is excessive, but I don't at all after having multiple decoders fail after years of use.
And I now realize why they failed.
There is no note from the decoder manufacturers about multiple axle pickups, and there should be.
Nor do they provide a way to connect the multiple axles to different pads for proper rectification and shoot through/short prevention.
Most DC model railroad engines currently link all axle pickups into a single circuit,
but this makes axle to axle shorts inevitable, and also makes the axles carry HALF of the RAIL current, AT ALL TIMES! VERY BAD!
So I solved it with this circuit, I hope I am not forgetting or not seeing any issues here.
This stuff isn't just some easy toy, it really requires one to think about conduction pathways.
I have modified the main schematic pdf to include this information.
IMHO, unless there is any possibility of some "flying-wires", coming from the "outside world", to invade your setup, you'll don't need FS11 (5A), at the GND path.
The other fuses are a must to have, for sure, and will provide enough protection for the circuits, as originally planned by you.
Pending to be detailed: the connections of FS3 (1A) (the "logic power supply" fuse) , but it is more than trivial, only needed for the sake of completeness.
(In fact, it was when I was looking for it (FS3), at the new power pickup wiring diagram, that my "internal" COWOX-rules checker started to "blip-blip-blip", warning me that there would be something to be double-checked.)
In time: COWOX stands for: "anywhere a COW goes, it's followed by an OX".
IMHO, unless there is any possibility of some "flying-wires", coming from the "outside world", to invade your setup, you'll don't need FS11 (5A), at the GND path.
Dude, you are DARN GOOD at picking the baddies!
YOU are so right, I did it again!, FS11 MUST GO!!!!
I can't believe I missed that one again! (i get used to putting fuses for AC...)
The other fuses are a must to have, for sure, and will provide enough protection for the circuits, as originally planned by you.
Pending to be detailed: the connections of FS3 (1A) (the "logic power supply" fuse) , but it is more than trivial, only needed for the sake of completeness.
(In fact, it was when I was looking for it (FS3), at the new power pickup wiring diagram, that my "internal" COWOX-rules checker started to "blip-blip-blip", warning me that there would be something to be double-checked.)
In time: COWOX stands for: "anywhere a COW goes, it's followed by an OX".
Yea, FS3 is to protect the logic from excessive current that could possibly come from the motor drive board connections, or possibly even the relay and smoker!
Thanks again! I will update schematic once I test my new fishing weights I installed inside the engine housing.
I was able to get 4 #4 lead weights in there, I hope that will be enough to increase the tractive effort!
(I think it almost doubled the weight of the engine, hehe) https://www.walmart.com/ip/Bullet-Weights-Cat-Pack-Bank-Sinkers-8-sinkers/946615995
Heres some long winded, ramblings.. (if you are interested in this thread, you may like it)
I tested the engine with the extra weight, and it performs beautifully.
It feels heavy, and the engine only, now weights 3lb 10oz, I do not know what the original weighs.
Because it worked so well I am not going to remove the weights to get the empty weight.
AND I DIDN'T NEED THE RUBBER ON THE WHEELS, OR HAVING TO FIGURE OUT HOW TO EPOXY RUBBER TO METAL!!!!
I SOOOO didn't want to do that, taking advantage of Tractive effort is AWESOME!
When running the engine the crappy electrical pickups on the tender would get dirty and need cleaning every few hours.
So I will be replacing the tender wheels with LGB #67403, i will need 4 of them so that is not cheap.
My caboose also now has 2 of the LGB #67403 electrical pickups, because one was dropping out every so often.
I also thought that using an accelerometer in the caboose would be great for measuring movement
to determine if the caboose or the cars got disconnected from the engine.
(this happens once in a great while due to my uneven track, which I am slowly making more even)
I would like the engine to stop if the caboose senses no movement but the engine is still at full throttle.
I have both the H48C three axis accelerometer but cannot find the product page for the support materials anymore.
I found beau's forum post about it that has the demo attached.
I also have the 2 axis accelerometer https://www.parallax.com/product/28017
I want the 3 axis to work for my use, but I think I will also get the 2axis working, since that was included in the Blocky Prop starter kit.
This means my caboose will have another propeller chip (it is my own custom pcb, the Mims Mirror, one of my previous projects here, minus the leds)
Both pickups will have a full wave rectifier each made out of 1n4001's.
To get the accelerometer data back to the engine prop and the webpage, I have another WX wifi module in the caboose.
This means I can get rid of the 555 flasher and just use the prop, then the EOT light can act as a functioning indicator for the caboose propeller.
The 1n4001 devices are only rated at 1.0A continuous, so with the accelerometer, the EOT, the prop chip and the WX wifi module,
plus a regulator for it all, I may need a bigger rectifier for the caboose, I will have to test that one when I get it all built.
I had to install a screw that keeps the tender attached to the engine due to variations in my track, it would sometimes disconnect.
I haven't purchased multiple rectifiers yet, so when my tender derailed a few times, it bridged the two tracks with two separate axles. When that happened, it caused the metal power pickup flap to start to melt into the plastic frame,
THIS IS ANTHER REASON WHY EACH AXLE NEEDS ITS OWN RECTIFIER CIRCUIT.
The following current measurement tests were done with all 4 cars in tow, and the extra weights in the engine. (engine weight of 3lb 10oz)
When running the track at 13.8v, and the new extra weight, the train goes just barely fast enough to pull 4 cars, the engine never has wheel slip anymore.
The log car that came with the bachmann kit, a boxcar I purchased, an engineering car I also purchased, plus the caboose.
Once in a while it will drop out and the train will stop due to bad tender pickups. With 13.8v track voltage, at full throttle and those 4 cars, the engine plus the caboose EOT light pulls 0.890 A PEAK, with the average at 0.400 A.
So under an amp all the time at full throttle, and all leds on, I forgot to turn on the smoker for that current test, i will need to do that again.
When changing the track voltage to 18v, at full throttle, the current is STILL ONLY 0.910 A PEAK!!!!
The speed is much better, it zips around the track and never drops connection from the lame tender bachmann pickups.
It also never has wheel slip and will slow down a bit when going up grade, pulling 0.910 A at that grade moment.
The average current at 18v track voltage is around 0.500 A.
The leds, the PAB, the motor, motor drive board, and the EOT all work very well at 18v track voltage,
but I don't have any TVS protection devices yet, so I think I want to increase my TVS VRWM to 19v.
I like that faster speed. 18v is HO setting on the PS2012 digitrax power supply.
I don't want to use the g-scale setting on the power supply (22v) because my PAB would be exposed to 20v or so, and its recommended max is 16.
I am about to install a temperature sensor DALLAS 1822 into the tender pushed against the motor drive board CHIP that pushes the motor.
I can then monitor on the control webpage, its temp in the mid hot sun, I may also put one on the motor its self so i can monitor its temp.
I might do the motor temp sensor when I do v2.0 of this thread due to then needing a second prop in the engine.
So far, I am completely satisfied with this project and circuitry, it has all performed excellent,
except the first time when I put fuses on the DC ground,
which blew and then used the prop as its ground, frying the prop.
If I had looked at the circuit long enough, I would probably have realized that was a bad idea.
The project uses multiple products from parallax, the motor drive board, the PAB, the WX esp WIFI module, the relay, the RFID board and tags,
and soon the hall effect sensor, and also the accelerometer, and in the future the servo to operate RR crossing arms.
I think this will be the biggest project that involves the most products from parallax all brought together, that I have ever done.
Parallax makes this easy by providing tested and true pcb's and circuits, along with example code, and users in this forum's example code.
I also like to support parallax due to them helping me in the past when I fried my SX key, my remote controller, and doing almost all of it OPEN SOURCE!
Im amazed that the peak current is just under 1 amp at full throttle at 18v and 4 fairly heavy cars, this means I can use smaller fuses in place of the 5 amp fuses, 2A would be good, and even overkill, 1.25 would be fine also.
I don't know what the current will get like when the motor gets old and abused, im sure it will rise.
I have not tried putting the motor drive board into full forward mode (non pwm) and measured the current,
perhaps I should try that, but I suspect it will not be much different if at all than 100% pwm (full throttle)
I may, in the future, purchase another northwoods logger set, so I can have two log cars, two engines (double headers are awesome).
Then I can also mess around with digital control and managing two trains on the same track with rfid sensor ZONES.
I do still need to work on mounting the RFID, the current feedback from the motor drive board, the axle sensor, plus the accelerometers.
More to come!
(if this is a toy, this is one HELL of a complicated toy, one that I don't think I have ever found, or will ever find, in TOYS R US.)
The RFID circuit is wired and now I need to modify the prop code, and webpage code to include it.
I will program the webpage to have a switch to make the engine stop at a specific rfid tag if the switch is on,
then I can stop the engine at a "station" by just telling it to stop at that tag.
( I like to stop my train at a specific spot on the layout to bring it inside, or to work on it or to take a lunch break.)
Eventually there will be a tag near the rail road crossing signals and arms that lower when the train is approaching.
The engineering car sits right behind the tender. The rfid device wouldn't fit in between the tenders wheels, but I don't mind.
Thats what the engineering car is for, right! All the cool tech stuff.
Right now its just wired by running a wire with connector between the engineering car and the tender,
but will eventually be powered by rail pickups, rectifier bridge, regulators a prop and yet another wx wifi device. (yea i have 4 of them)
You can see the reader mounted on the bottom of the engineering car, and you can see the tag is below the sleepers.
I will post the updated code after I test it, technically I have not tested the rfid and tag with 18v DC going through the brass tracks.
(along with all the noise that motors make and current fluctuations in the track) And I have no idea what DCC on the tracks would do to the rfid reader.
I think the DC will work fine, but the dcc.. thats a different story. I will test the dc, but I don't have a dcc command station anymore, so I will not be testing that.
The RFID additional spin code and html code should be posted tomorrow.
The RFID code only works when the train is traveling very slow, which isn't what I want.
It was pretty consistent in that, when at max speed, or medium speed, the rfid reader passed over the tag too quickly and would not read it.
It did work pretty consistently when traveling slow, and I am sure the problem isn't the rfid loop, because I modified it to loop fast as possible.
You can check out the code I used, its attached, I won't change the first post code to include the rfid because it won't work for G-scale trains. (they are too fast)
The rfid feedback can only be seen on the telnet connection.
I even tried to move the rfid reader closer to the track with longer aluminum standoffs, and I also removed the steel thumb screws in case that interfered.
Nothing helped, the reader and card are just not fast enough for a proper and consistent read at faster speeds, actually it wouldn't read at all at the fast speeds.
So I will be now looking for another solution to ZONE identification. I had hoped the rfid would work, but my initial tests were not at max speed.
I don't think a hall effect sensor will work because the distance it needs to be from the magnet is too close.
I am now going to look into BARCODE laser scanners to see if any cheap miniaturized versions exist (i doubt it).
I suspect my only options now are:
1. IR sensor that reads pulses from a ir emitter in between the ties to make the signal unique. But this might be iffy... (just like a tv remote)
But I didn't want the track to have any complicated circuitry, moisture, rain, sprinkler, the uv from the sun beating the IR emitter directly....
(I suppose I could make a 9v powered prop pulse an IR emitter with specific code for the IR receiver on the train, and put it in a small sealed box)
2. Track with zone isolators (plastic rail joiners) that isolate sections of track from each other that means circuitry that can detect it also.
This is starting to get back to track DCC. (this is probably the only option I realistically have)
3. Machine vision camera for unique track marking ID, (not realistic or cheap)
4. A physical switch that is closed by physical contact with the train (i would rather just do track zone isolators methods, I don't want physical contact with the train)
5. You suggest something? The requirements are that the part on the track is passive(no power), and the parts on the train can be active(powered and logic communications)
I will put zone detection aside for now, like I did the sound, and start on accelerometer feedback from the caboose.
First I will try the 2d unit that is currently being sold on the parallax store. #28017 Mx2125
This means the caboose will now get a propeller, a WX wifi device, a 3.3v regulator, with the prop controlling the EOT also.
This also means the WX wifi caboose to WX wifi tender communications need to be coded, so this part of the project will take a few days to figure out.
I am not too sure on how to mount the accelerometer, the track bumps will be up and down and continuous.
The forward, stop, reverse motion will only be momentary and slightly fluctuate due to motor and grade changes.
The side to side motion of the cars rocking from uneven track will be continuous.
I think having it mounted so it detects the bumps in the track (up and down) and the rocking perpendicular to the track might be best.
I recall someone saying I wasn't descriptive and my discussions weren't long enough on my posts, so I have tried to increase my text effort(long winded-ness), how am I doing? ;P
@Clock Loop, I think you might be pleasantly surprised if you tried using a simple barcode setup. With a barcode label on the track and a led/photo-transistor under the engine the motion of the train can be used to scan the barcode. This method is in use for many applications.
@Clock Loop, I think you might be pleasantly surprised if you tried using a simple barcode setup. With a barcode label on the track and a led/photo-transistor under the engine the motion of the train can be used to scan the barcode. This method is in use for many applications.
Clock Loop,
I think that Kwinn is correct, I believe even the real railroads use trackside barcode sensors and barcodes to identify freight cars.
Jim.
IM CONVINCED! Now to find the proper equipment...
Here is the latest caboose code.
It shows the accelerometer on the caboose webpage, and lets you turn the EOT on or off.
The EOT is also controlled by the prop in the caboose.
The caboose has its own rail power pickups, parallax Wx wifi device, a prop, a memsic 2125 accelerometer,
a 3.3v regulator and 2 full wave rectifiers made out of 8 1n4001's (one per axle), an internal RGB led (for hearbeat if EOT is off) and the red EOT on the rear coupler.
(see attached image below)
I haven't coded Engine to Caboose communcations to get the accelerometer data to the engine for lack of movement Alarm and emergency stop.
For now I will monitor the web page for values that are normal for movement, and values that are normal for no movement.
the schematic for the new caboose circuit will be added to the main schematic.
I will keep the 555 timer EOT schematic with it in case others want a 555 eot instead.
I put it all on a breadboard, and stuck that inside the caboose for now, it fits exactly.
I didn't use a prop DIP because my supply of 55+ propeller dips was eliminated by badge wearin' crakhead psychopathic boozerz. (no really)
So I just used a prop I made that already had the 3.3v regulator, and wires,
The prop is the bizarre lookin star shape with a prop chip on top that was magnet wired together, got patience? (thanks Sally Hansen® and the beauty isle at walgreens, GET TO THE POINT!)
The zip file contains the v1.2 WX esp8266 firmware along with a linux (.sh) and windows (.bat) files needed to program it.
(this is just to update a factory WX wifi to v1.2 which has many enhanced features, it doesn't contain the engine or caboose files, you need to upload them to the WX device)
The zip also has the html for the engine which has been updated to show the current pwm on the webpage(every second updates automagically)(spin code was updated also)
And it has the html for the caboose to show the accelerometer output on the webpage(updates every 3 seconds automagically) and it has a switch for the EOT light.
Lets see what other kind of useless unimportant long winded toy garbage can i upload here... hmmm.
I suppose I will look into barcode scanning now. And continue to work on the accelerometer feedback from the caboose to the engine.
I am not doing the motor drive board current feedback using the PAB a2d because I don't have a PROPER axle sensor yet.
Updated schematic and this zip file will be put on the first post when I get the new schematic additions done.
L8r!
P.S. DO NOT HAVE THE WEBPAGE OPEN if you are (re)programming the prop, it will mess up the programming,
also DO NOT HAVE THE TELNET terminal open while programming, that will mess up the programming also.
These WX things have a limited amount of sockets available from what @"David Betz" has previously stated in my WXesp8266 fimware compile thread.
We all derail, its inevitable, what matters is the aftermath and how we clean it up, and change our ways,
many just leave the train wreck in place, due to arrogance, a lack of care, and a failure to even recognize any fault at all.
My fault with this derail wreck was I oiled the axles with drippy oil, instead of lithium grease,
the oil got on the tracks and made them too slick, the engine hit the switch with less than perfection and jumped the track.
Without re-reading the whole thread, and I do recall you mentioning using WiFi or Bluetooth. There is also the 433MHz/etc alternatives too. On another thread the RN42 is discussed and while $$ the current is ~50mA max which is good.
Now, for existing trains and tracks, DCC is likely used. New "your smart" trains can be added to the tracks without changing the existing track and trains. Your method of voltage recover will work just fine with them.
So what does your "smart" train(s) need?
A "smart transmitter" to control the "smart" trains. It can be any smart computer device with software. It just needs to know the addresses of the "smart" trains. Transmitter is obviously a transceiver but it is the master
The "Smart train(s)" need a compatible receiver (receiver is obviously a transceiver but it is the slave(s)).
* power recovery from the tracks - compatible with DCC but just recovers power - your basic circuit a number of posts back fulfills this requirement.
* position detection around the track - reading a barcode on the track would be the easiest way to go as it only requires barcodes to be placed around the tracks although they could require replacement due to UV and weather degradation. The alternative is the train has the barcode and scanners are placed around the track - more work as it has to be fitted and wired even if wireless as it will require power. Other ideas also given below.
* "smarts" inside the smart train - a micro with wireless (wifi/bluetooth/433MHz/etc) communications to the master controller.
Each train would need to be assigned a mac or similar. The same is needed for existing DCC trains anyway. The mac style is likely to be unique meaning trains do not need to be programmed each time they go onto a track.
Barcode Detection
It may be possible to also read the barcode from the side rather than under the track. This could mean that a sign with a barcode, similar to the station signs on the platform could be used. Much easier to place around the track?? Just need to standardise on height. This would be much easier than to have the barcode on the track - under the track would get interference from the sleepers.
Another option may be to use the sleepers as the barcode gap, and the area in between the sleepers to code a "0" or "1" by being black or white. Not sure how many bits you might get between the sleepers. A barcode doesn't actually need to be a real barcode, just a sequence of 0's and 1's to get an 'n' bit code.
I have noticed my Parallax WX wifi devices I use now (#32420) use lots of power.
The caps I have on the track voltage after the rectifier do very well in keeping the motor powered and the wifi device powered during serious power drops.
(I can put a paper towel on the track that is 4 inches wide and the motor plus tender will handle it) (i do this to clean the wheels, once in a while)
I have found supercaps are probably not worth the trouble, the many issues described in this thread... https://forums.parallax.com/discussion/146613/supercap-application-question
I am going to try putting my supercap on the track voltage side for my caboose circuit, by stacking 2.7v caps, but their lifetime sucks, so using a very large cap like I use now is probably best.
Barcode Detection
, and the area in between the sleepers to code a "0" or "1" by being black or white.
Thats not a bad idea.
I would only need 4 bits, that would give me 16 different values, but this involved timing, speed requirements, etc..
Start bit, and a stop bit.. plus data bits... etc.. i think speed might be a factor here...
A diode laser barcode scanner would make this much easier?, laminated laser printed barcodes...?
Definitely not a cheap or small way to go.
I thought about using a ping perhaps and fill the space between the sleepers with material to make it the same height as the sleepers, or vice versa.
But the ping seems like its kinda wide.
But the laser ping might actually work and its hole out the bottom of the car would be small.
The minimum range is .78 inch, and g-scale wheel diameter is about 1.5 inch.
An issue might be any thing like a switch, or a lgb isolator piece of track.
However, objects could be put in between the track that rise to the same height as the track, which is far above the sleepers,
that would give clear distinction from the sleepers and between the sleepers.
It would still get close to what switches, crossovers, and other track intersections do though.
But a long piece of something the same height as the track would be distinct.
G-scale switches are about 1 foot in length, and some are even longer 1.5.
So any object that is used with laser ping would need to be even longer than any single object.
I would think piece of wood at the height of the track, which is 4 inches long (used as a start bit) and then notches cut out on the last few inches could be detected with the laser pin?
The sparkfun laser scanner looks like it will fit into an HO boxcar (pointing down)
(my desire is to make all this also work in HO) its only 1inch wide or so, and 2 inch long(with the sparkfun pcb)
It looks like it can be removed from the sparkfun pcb and just have the ribbon cable connected
so that would help with mounting it in HO, it looks like the sparkfun pcb is screwed to it.
I also wonder if the mirrors of the sparkfun laser scanner would get damaged from rail shock, if that is even an issue with it.
I know shock is a big issue with handheld barcode scanners.
I won't even try to fit it all in N-scale, that is a nightmare. I have a large n-scale layout and I know that its VERY hard to work with.
I have a color pal but its required distance is too close.
For simplicity and cheap price, and I already have multiple IR sensors and emitters... I will test with a simple IR led and sensor.
I don't have the money for that laser scanner, or the laser ping.
My concern here is the brick and grass in between the sleepers...
I guess the only option I have is install a IR sensor and emitter and try it to see how the brick and grass and dirt and other materials are detected.
But then I get to deal with different sun intensities, different angles, night time, etc.
This shouldn't be this hard, lol, the IR method won here simply due to money. I will give that a try.
As a few of us have said, you're on the wrong track regarding supercaps and large caps - pun intended. You need to read up on capacitance charge calculation.
Take a look at the cheap line follower robot cars - a very simple circuit that can tell the difference between black and white which is all you are trying to do to read a barcode. Remember barcodes are really fine lines - you don't need them to be this fine and a larger bar can be read much simply.
I keep forgetting that the track is huge (ie not bedroom size). Why not try a GPS in the train - might be accurate enough. It won't tell you which track you're on when they are side by side, but might give you enough info.
The bar code idea is good though. Get one of those line follower modules (super cheap), then print some barcodes where the black and white areas are large (since your train will pass over pretty fast). Then mount the line follower module facing down under your loco, and stick the barcodes in the track between the rails.
If you raise and center the barcode between the rails it should reduce the effects of ambient light, and if that is not enough you could put a shroud around it as well. Add a well designed barcode with a parity bit or simple crc check and it should work.
What's wrong with having an IR LED on the train that is continually pulsing out a fixed code that is read by an IR receiver on or besides the track? The IR LED would be run at low power and at the end of a length of tube to limit the radiation pattern but angled towards or away, maybe one for both. The make and break codes confirm the passing of the carriage.
You can even do this with an IR LED itself as the receiver so that each end uses only a single LED both for transmitter and receiver. I did this on a couple of products and implemented two-way serial communications over several meters.
btw, the code could be something as simple as a frequency or else a use a cheap sot-23 3 cent mcu to generate the code and carrier.
What's wrong with having an IR LED on the train that is continually pulsing out a fixed code that is read by an IR receiver on or besides the track? The IR LED would be run at low power and at the end of a length of tube to limit the radiation pattern but angled towards or away, maybe one for both. The make and break codes confirm the passing of the carriage.
You can even do this with an IR LED itself as the receiver so that each end uses only a single LED both for transmitter and receiver. I did this on a couple of products and implemented two-way serial communications over several meters.
btw, the code could be something as simple as a frequency or else a use a cheap sot-23 3 cent mcu to generate the code and carrier.
Trying to minimise what needs to be added to the track layout. Anything passive is much easier than anything requiring wiring.
As a few of us have said, you're on the wrong track regarding supercaps and large caps - pun intended. You need to read up on capacitance charge calculation.
What are you saying, my caps are too big? No rush limiter? etc? ??? With the wifi modules, and a motor, I don't see how I can deal with very bad track connections, unless I use a battery or large cap. I haven't had issues yet, but perhaps you see an issue? Can you explain?
Why not try a GPS in the train - might be accurate enough. It won't tell you which track you're on when they are side by side, but might give you enough info.
That could be possible I think, gps is 3 feet or so accurate, military gps is much more accurate, but encrypted,
but I kinda wanted to be HO compatible and even n if I can fit it.
I actually have a few of the bxp88's, and they do work well for current detection, but their transponding ability depends on the decoder you choose (do NOT use the sdxn136ps decoder if you want to do transponding, it mixes up its transponder with all other layout transponders regardless of the zone they are in. Its like a clown show, you don't know whos comin' or goin'.
Once my dcs240 blew up because I ran an engine from the main track to the programming track when the programming track switch was on,
it killed the entire command station. That was the end of my DCC experience, and since the bxp88's need it, those are useless also,
along with some DS64's. I may end up making my own versions of everything, since I know how they all work,
I just wont use loconet or the digitrax transponding system, I will make my own up.
The problem with zones is they require 1 wire per zone, that means I am running a bunch of outdoor wire, and its possible this may be the only way.
I am going to try other things first before I fall back on zone current detection.
If you raise and center the barcode between the rails it should reduce the effects of ambient light, and if that is not enough you could put a shroud around it as well. Add a well designed barcode with a parity bit or simple crc check and it should work.
I will definetly have to look into trying that possibly with the line follower modules...
btw, the code could be something as simple as a frequency or else a use a cheap sot-23 3 cent mcu to generate the code and carrier.
Like cluso99 says, I cannot/dont want to install powered things on or around the track, its all outdoors.
I am willing to have some limited exceptions like rr crossings, but I will need to outdoorproof them
So anything electronic must be on the train, the track can power things, but that means those things must also be taken apart and brought inside.
Ok, think about water, snow, wind, HAIL, 90 degree direct sun, etc, bugs, raccoons, cats, skunks... etc..
OUTDOOR!
Thanks for the PHOTON PLATFORM and PARTS, PARALLAX, the PROPELLER, makes PROTOTYPING with PHOTOS, PHUN!
I am not skill, I have no employable. DO NOT BELIEVE THE HYPE, only believe the everyday mundane edjumication.
I have updated the schematic to allow 18v track voltage since my motor does better at that voltage than 14v.
That means I had to increase all the TVS devices to 20v, and also the activity board WX needs to be REV B or C, REV A only allows 15v max.
I have AWB rev A, so i guess we will see how long it lasts with the two diode vf drops between it and 18v track voltage.
My max draw through the first rectifier diodes is less than 1 amp, that means a vf of less than 1v (but there are two diodes in the full wave rectifier package)
and I have a 1n4001 just before the AWB, but that one will likely draw much less than 1amp
so I will be on the egde of max allowable voltage to the PWB rev A. I will probably be ok. (so far so good)
I have included the caboose code in the zip file on the first post and the schematics to include the caboose circuitry.
The caboose code also now includes a swinging lantern control, the webpage also has a switch for it.
I have included pause code between commands to the WX device because sometimes when running the POLL command
it interprets it as something to output to the telnet serial interface, which then shows the word POLL on your debug telnet terminal.
Kind of an odd bug...
I WAS using the command
ser.str(string("POLL:"))
And I don't think I should be including the colon without a value after, not sure if it matters, but
ser.str(string("POLL"))
works also, so I will do more testing to see if the problem still shows.
The motor code was changed a bit to deal with pwm numbers higher than 100 or lower than 0, this is because the code
Repeat CurrentDuty from CurrentDuty to Speed
I should probably do this differently, but it works with the checks...
I also combined the forward and reverse code so it reads easier.
I am trying to comment better, some comments were left over from copied code when the code was changed but the comment was not.
I may still have some comments that are incorrect, I will fix as I find them!
The first post has the updated schematic, and the zipped code.
With 2 or more WX wifi devices its highly recommended that any user get a dedicated wifi router that is not on the internet
to link all the devices and your webpage control method (tablet, pc, phone etc),
then the next revisions of code will work when I implement an emergency stop if the caboose's accelerometer detects no movement.
When you name the WX devices, my code will expect the names to be, "Engine" for the engine, and "Caboose" for the caboose.
The router needs to be able to properly deal with local DNS names for this to work, if you name your local domain something like RR.local,
Then you can use common names like engine.rr.local to access the config page or engine.rr.local/files/index.html to access the control page.
I haven't tested if the connect command in the WX module can use dns names or if it requires specific ip numbers, I hope it can do dns names.
Wireless communications instead of DCC sure does make this easier, no transponding, the wifi devices already have the ability to be uniquely named etc.
The protocols are already there for you.. Your wifi router basically becomes your command station to link it all.
More pics and a few videos.
Xvid video codec and Flac audio codec, avi format.
I also added m4v format for crapple users.
I still haven't purchased my grease so the tender wheels squeek.
The REAL wood makes the log car heavier, which prevents some derailments around curves from the heavier cars behind it.
Somebody stop MEH, im havin too much fun.
Now I need to find a G-scale log crane to modify with parallax servos, motor drive board, wx wifi, etc, then I can load the logs also.
So it turns out that the WX module DOES resolve dns names properly.
THAT IS AWESOME.
I am trying out the WX examples in the SIMPLE TOOLS LEARN folder.
Learn\Examples\Network\WiFi\Prop to Prop via WX (Client).side
Learn\Examples\Network\WiFi\Prop to Prop via WX (Host).side https://github.com/parallaxinc/Simple-Libraries/releases
I just changed the ip to my hosts dns name.
My caboose will be sending its accelerometer values to the engine in no time... EXCELLENT!
This also paves the way for the engine to detect its position on the track (with linescan or laser ping)
and then contact the railroad crossing prop to turn on the crossing lights, bell, and lower the arms. (once I make it all)
Whoever made these C examples did a great job providing many different examples, thank you! (parallax?)
For some reason my Client.side file couldn't find the "sscanAfterStr" function even though its in the library.
So I modified the Prop to Prop via WX (Client).side file to include that function inside the file its self.
I also slowed the whole thing down so I can snoop the tx and rx lines to get how it works and convert it to spin.
Once I have a spin example working it will be posted in my WX compile thread like the other examples.
Heres the modified Prop to Prop via WX (Client).c file.
/*
Prop to Prop via WX (Client).c
Sends TCP GET request to host, and displays values in responses.
NOTE: The TCP message this page sends is very similar to what the browser sends in response to
an update button click in:
http://learn.parallax.com/tutorials/language/propeller-c/parallax-wx-wi-fi-module-prop-c/page-requests-info-propeller
*/
#include "simpletools.h" // Library includes
#include "wifi.h"
// IMPORTANT: Use the IP address for your host WX in both the hostIP
// and request strings.
char hostIP[] = "caboose.rr.local"; // Host IP address
char request[] = // TCP GET request
"GET /tpfm HTTP/1.1\r\n"\
"Host: caboose.rr.local\r\n"\
"Connection: keep-alive\r\n"\
"Accept: *" "/" "*\r\n\r\n";
int event, id, handle; // wifi_poll variables
char tcp_str[256]; // TCP string
int x = 0, y = 0; // Test values
int sscanAfterStr(char *buffer, char *str, char *fmt, ...){
char *loc = strstr(buffer, str);
loc += strlen(str);
va_list args;
va_start(args, fmt);
int blocks = _doscanf(loc, fmt, args);
va_end(args);
return blocks;
}
int main() // Main function
{
wifi_start(31, 30, 115200, WX_ALL_COM); // Start wifi in other processor
wifi_setBuffer(tcp_str, sizeof(tcp_str)); // Use tcp_str instead of default
while(1) // Main loop
{
int tcpHandle = 0; // Poll for handle
while(tcpHandle < 5)
{
tcpHandle = wifi_connect(hostIP, 80); // Try to open connection
}
// Send TCP request via connection handle
wifi_print(TCP, tcpHandle, "%s", request);
for(int n = 0; n < 100; n++) // Poll for response
{
wifi_poll(&event, &id, &handle); // Check event
pause(5000);
if(event == 'D') // If data received...
{
wifi_scan(TCP, tcpHandle, // Store data in tcp_str
"%s", tcp_str);
// Get values after x= and y=
sscanAfterStr(tcp_str, "x=", "%d", &x);
sscanAfterStr(tcp_str, "y=", "%d", &y);
// Display values
print("Client: x = %d, y = %d\r", x, y);
// After processing x and y, preak out of the for... loop
break;
}
}
wifi_disconnect(tcpHandle); // Disconnect after exhcange
// IMPORTANT: Frequency of requests should be less than max response
// frequency. So, make sure to a pause here that's longer
// than in host back end code.
pause(5000);
}
}
Heres a copy of the code that communicates with the caboose to determine if caboose is moving.
If it is not moving it will say on the telnet terminal connection.
No action or webpage feedback has been implemented yet to do anything with a lack of caboose movement.
It shows no movement if the accelerometer values are 0 or the change from the last value is less than 3. (absolute)
Much more is involved with the WX module when making a prop talk to a prop.
The code also commands the WX module to close all connections at startup (the prop might restart from lack of track connection
when lacking voltage props drop out before the wifi does. So I command all WX connections to stop at startup.
Comments
I have edited prior posts, in this thread and even others. I have no problem admitting fault, even if others will not.
I could continue But someone needs to put an end to this.
Even if I disagree with you and others, I understand that forum civility is more important than me making my point.
And so the saying goes "Its nice to be important, but more important to be nice."
And to finish!
Can't you hear the captain shouting, "Dinah, blow your horn!" Dinah, won't you blow, Dinah, won't you blow, Dinah, won't you blow your horn? Dinah, won't you blow, Dinah, won't you blow, Dinah, won't you blow your horn? Someone's in the kitchen with Dinah Someone's in the kitchen I know Someone's in the kitchen with Dinah Strummin' on the old banjo! Singin' fee, fie, fiddly-i-o Fee, fie, fiddly-i-o-o-o-o Fee, fie, fiddly-i-o Strummin' on the old banjo.Feel free to make any comments about the circuit, and leave out any personal insults, or basic knowledge of electronics, "jabs", thank you.
ITS AN AMBUSH!
Here is an EOT that I am working on, dcc friendly.
Gotta have a light for that caboose, so you know if your cars are still attached to your engine at night.
I replaced the wheels in the caboose with LGB #67403 wheels with electrical pickups.
I probably only need 1 wheel with electrical pickups, and may use the other in another car.
This led is a Luxeon Rebel DEEP RED for the EOT.
https://www.digikey.com/product-detail/en/lumileds/LXZ1-PA01/1416-1051-1-ND/3961156
You can connect the lantern to the ceiling of the caboose using double loops of bare wire,
so the lantern will give a SWING effect from movement down the track, it will even flicker as it swings, giving it a flickering lantern look.
NEAT! eh?
The lantern is a Luxeon Z 4000k Neutral White.
https://www.digikey.com/product-detail/en/lumileds/LXZ1-4070/1416-1050-1-ND/3961155
I didn't choose the amber for the lantern, because the engine headlight is amber.
One could use a lower temp led, like a 2700k warm white led that is a more red white color.
Digikey dosen't stock them, but a net search might find some or other low temp 3000k or less color.
https://www.digikey.com/product-detail/en/lumileds/LXZ1-2780-3/1416-1138-1-ND/4340038
Its deadbug style.
It works GREAT!
I guess the insults STAND, as per the forum mod. GREAT! I have never insulted anyone here to that degree, ever.
Thats real nice.
No really.
Time to make more tedious, looser, toy train posts. Lets see, what else can I make....
I KNOW, I can finish my lantern and post that TEDIOUS LOOSER TOY GARBAGE. YAAY!
I do know the covid stuff and lockdown is making people edgy. Calm down all of you.
You @"Clock Loop" are a long standing forum member with funny projects, so I don't bite on not having ' basic knowledge of electronics' you do have them, don't worry. And you are definitely not a looser.
@"Peter Jakacki" is normally also a very helpful person, it is just that everybodies nerves seem to get thin lately.
This forum was, is and should be in the future a exception of the bullying tenor found in a lot of other online forms of communication lately.
And yes @jonabel1971, I am looking at you too.
One should avoid taking critic or unexpected replies as 'personal injuries' and should avoid doing attacks on others.
As a regular and long time member of this forum I am astonished, appalled and disturbed by the change in manners lately in discussions, and yes @"Peter Jakacki" I can understand your reactions to @bbrien, but hell he is what? 72 or so and started a major (for him) project.
Is there really a need to type up that sawtooth post instead of just saying nothing?
Patience!
Guys and Gals, be NICE to each other, everybody has some pressure going on this year and it does not help at all to start small fights everywhere.
Do it like those steam engines and to release pressure and just whistle or whatever they do.
And YES @"Clock Loop" I am interested in your posts, even if they mention non Parallax solutions, this is or should be a technical forum for EE's and Hobbyists who do something and need or found a solution.
Anyways, PLEASE we NEED to stay calm and friendly, all of us.
Mike
Mike
A NOTE ON POWER PICKUP FROM THE TRACK TO THE WHEELS.
PREVENT SHOOT THROUGH.
PREVENT DIRECT SHORTS FROM DIFFERENT ZONES.
PREVENT REVERSE LOOP SHORTS!!!
(at least from axle to axle, very temporary shorts happen when the wheel bridges the zone isolator)
Some may think this is excessive, but I don't at all after having multiple decoders fail after years of use.
And I now realize why they failed.
There is no note from the decoder manufacturers about multiple axle pickups, and there should be.
Nor do they provide a way to connect the multiple axles to different pads for proper rectification and shoot through/short prevention.
Most DC model railroad engines currently link all axle pickups into a single circuit,
but this makes axle to axle shorts inevitable, and also makes the axles carry HALF of the RAIL current, AT ALL TIMES! VERY BAD!
So I solved it with this circuit, I hope I am not forgetting or not seeing any issues here.
This stuff isn't just some easy toy, it really requires one to think about conduction pathways.
I have modified the main schematic pdf to include this information.
IMHO, unless there is any possibility of some "flying-wires", coming from the "outside world", to invade your setup, you'll don't need FS11 (5A), at the GND path.
The other fuses are a must to have, for sure, and will provide enough protection for the circuits, as originally planned by you.
Pending to be detailed: the connections of FS3 (1A) (the "logic power supply" fuse) , but it is more than trivial, only needed for the sake of completeness.
(In fact, it was when I was looking for it (FS3), at the new power pickup wiring diagram, that my "internal" COWOX-rules checker started to "blip-blip-blip", warning me that there would be something to be double-checked.)
In time: COWOX stands for: "anywhere a COW goes, it's followed by an OX".
Dude, you are DARN GOOD at picking the baddies!
YOU are so right, I did it again!, FS11 MUST GO!!!!
I can't believe I missed that one again! (i get used to putting fuses for AC...)
Yea, FS3 is to protect the logic from excessive current that could possibly come from the motor drive board connections, or possibly even the relay and smoker!
Thanks again! I will update schematic once I test my new fishing weights I installed inside the engine housing.
I was able to get 4 #4 lead weights in there, I hope that will be enough to increase the tractive effort!
(I think it almost doubled the weight of the engine, hehe)
https://www.walmart.com/ip/Bullet-Weights-Cat-Pack-Bank-Sinkers-8-sinkers/946615995
I tested the engine with the extra weight, and it performs beautifully.
It feels heavy, and the engine only, now weights 3lb 10oz, I do not know what the original weighs.
Because it worked so well I am not going to remove the weights to get the empty weight.
AND I DIDN'T NEED THE RUBBER ON THE WHEELS, OR HAVING TO FIGURE OUT HOW TO EPOXY RUBBER TO METAL!!!!
I SOOOO didn't want to do that, taking advantage of Tractive effort is AWESOME!
When running the engine the crappy electrical pickups on the tender would get dirty and need cleaning every few hours.
So I will be replacing the tender wheels with LGB #67403, i will need 4 of them so that is not cheap.
My caboose also now has 2 of the LGB #67403 electrical pickups, because one was dropping out every so often.
I also thought that using an accelerometer in the caboose would be great for measuring movement
to determine if the caboose or the cars got disconnected from the engine.
(this happens once in a great while due to my uneven track, which I am slowly making more even)
I would like the engine to stop if the caboose senses no movement but the engine is still at full throttle.
I have both the H48C three axis accelerometer but cannot find the product page for the support materials anymore.
I found beau's forum post about it that has the demo attached.
I also have the 2 axis accelerometer https://www.parallax.com/product/28017
I want the 3 axis to work for my use, but I think I will also get the 2axis working, since that was included in the Blocky Prop starter kit.
This means my caboose will have another propeller chip (it is my own custom pcb, the Mims Mirror, one of my previous projects here, minus the leds)
Both pickups will have a full wave rectifier each made out of 1n4001's.
To get the accelerometer data back to the engine prop and the webpage, I have another WX wifi module in the caboose.
This means I can get rid of the 555 flasher and just use the prop, then the EOT light can act as a functioning indicator for the caboose propeller.
The 1n4001 devices are only rated at 1.0A continuous, so with the accelerometer, the EOT, the prop chip and the WX wifi module,
plus a regulator for it all, I may need a bigger rectifier for the caboose, I will have to test that one when I get it all built.
I had to install a screw that keeps the tender attached to the engine due to variations in my track, it would sometimes disconnect.
I haven't purchased multiple rectifiers yet, so when my tender derailed a few times, it bridged the two tracks with two separate axles.
When that happened, it caused the metal power pickup flap to start to melt into the plastic frame,
THIS IS ANTHER REASON WHY EACH AXLE NEEDS ITS OWN RECTIFIER CIRCUIT.
The following current measurement tests were done with all 4 cars in tow, and the extra weights in the engine. (engine weight of 3lb 10oz)
When running the track at 13.8v, and the new extra weight, the train goes just barely fast enough to pull 4 cars, the engine never has wheel slip anymore.
The log car that came with the bachmann kit, a boxcar I purchased, an engineering car I also purchased, plus the caboose.
Once in a while it will drop out and the train will stop due to bad tender pickups.
With 13.8v track voltage, at full throttle and those 4 cars, the engine plus the caboose EOT light pulls 0.890 A PEAK, with the average at 0.400 A.
So under an amp all the time at full throttle, and all leds on, I forgot to turn on the smoker for that current test, i will need to do that again.
When changing the track voltage to 18v, at full throttle, the current is STILL ONLY 0.910 A PEAK!!!!
The speed is much better, it zips around the track and never drops connection from the lame tender bachmann pickups.
It also never has wheel slip and will slow down a bit when going up grade, pulling 0.910 A at that grade moment.
The average current at 18v track voltage is around 0.500 A.
The leds, the PAB, the motor, motor drive board, and the EOT all work very well at 18v track voltage,
but I don't have any TVS protection devices yet, so I think I want to increase my TVS VRWM to 19v.
I like that faster speed. 18v is HO setting on the PS2012 digitrax power supply.
I don't want to use the g-scale setting on the power supply (22v) because my PAB would be exposed to 20v or so, and its recommended max is 16.
I am about to install a temperature sensor DALLAS 1822 into the tender pushed against the motor drive board CHIP that pushes the motor.
I can then monitor on the control webpage, its temp in the mid hot sun, I may also put one on the motor its self so i can monitor its temp.
I might do the motor temp sensor when I do v2.0 of this thread due to then needing a second prop in the engine.
So far, I am completely satisfied with this project and circuitry, it has all performed excellent,
except the first time when I put fuses on the DC ground,
which blew and then used the prop as its ground, frying the prop.
If I had looked at the circuit long enough, I would probably have realized that was a bad idea.
The project uses multiple products from parallax, the motor drive board, the PAB, the WX esp WIFI module, the relay, the RFID board and tags,
and soon the hall effect sensor, and also the accelerometer, and in the future the servo to operate RR crossing arms.
I think this will be the biggest project that involves the most products from parallax all brought together, that I have ever done.
Parallax makes this easy by providing tested and true pcb's and circuits, along with example code, and users in this forum's example code.
I also like to support parallax due to them helping me in the past when I fried my SX key, my remote controller, and doing almost all of it OPEN SOURCE!
Im amazed that the peak current is just under 1 amp at full throttle at 18v and 4 fairly heavy cars, this means I can use smaller fuses in place of the 5 amp fuses, 2A would be good, and even overkill, 1.25 would be fine also.
I don't know what the current will get like when the motor gets old and abused, im sure it will rise.
I have not tried putting the motor drive board into full forward mode (non pwm) and measured the current,
perhaps I should try that, but I suspect it will not be much different if at all than 100% pwm (full throttle)
I may, in the future, purchase another northwoods logger set, so I can have two log cars, two engines (double headers are awesome).
Then I can also mess around with digital control and managing two trains on the same track with rfid sensor ZONES.
I do still need to work on mounting the RFID, the current feedback from the motor drive board, the axle sensor, plus the accelerometers.
More to come!
(if this is a toy, this is one HELL of a complicated toy, one that I don't think I have ever found, or will ever find, in TOYS R US.)
Thanks again!
The RFID circuit is wired and now I need to modify the prop code, and webpage code to include it.
I will program the webpage to have a switch to make the engine stop at a specific rfid tag if the switch is on,
then I can stop the engine at a "station" by just telling it to stop at that tag.
( I like to stop my train at a specific spot on the layout to bring it inside, or to work on it or to take a lunch break.)
Eventually there will be a tag near the rail road crossing signals and arms that lower when the train is approaching.
The engineering car sits right behind the tender. The rfid device wouldn't fit in between the tenders wheels, but I don't mind.
Thats what the engineering car is for, right! All the cool tech stuff.
Right now its just wired by running a wire with connector between the engineering car and the tender,
but will eventually be powered by rail pickups, rectifier bridge, regulators a prop and yet another wx wifi device. (yea i have 4 of them)
You can see the reader mounted on the bottom of the engineering car, and you can see the tag is below the sleepers.
I will post the updated code after I test it, technically I have not tested the rfid and tag with 18v DC going through the brass tracks.
(along with all the noise that motors make and current fluctuations in the track) And I have no idea what DCC on the tracks would do to the rfid reader.
I think the DC will work fine, but the dcc.. thats a different story. I will test the dc, but I don't have a dcc command station anymore, so I will not be testing that.
The RFID additional spin code and html code should be posted tomorrow.
It was pretty consistent in that, when at max speed, or medium speed, the rfid reader passed over the tag too quickly and would not read it.
It did work pretty consistently when traveling slow, and I am sure the problem isn't the rfid loop, because I modified it to loop fast as possible.
You can check out the code I used, its attached, I won't change the first post code to include the rfid because it won't work for G-scale trains. (they are too fast)
The rfid feedback can only be seen on the telnet connection.
I even tried to move the rfid reader closer to the track with longer aluminum standoffs, and I also removed the steel thumb screws in case that interfered.
Nothing helped, the reader and card are just not fast enough for a proper and consistent read at faster speeds, actually it wouldn't read at all at the fast speeds.
So I will be now looking for another solution to ZONE identification. I had hoped the rfid would work, but my initial tests were not at max speed.
I don't think a hall effect sensor will work because the distance it needs to be from the magnet is too close.
I am now going to look into BARCODE laser scanners to see if any cheap miniaturized versions exist (i doubt it).
I suspect my only options now are:
1. IR sensor that reads pulses from a ir emitter in between the ties to make the signal unique. But this might be iffy... (just like a tv remote)
But I didn't want the track to have any complicated circuitry, moisture, rain, sprinkler, the uv from the sun beating the IR emitter directly....
(I suppose I could make a 9v powered prop pulse an IR emitter with specific code for the IR receiver on the train, and put it in a small sealed box)
2. Track with zone isolators (plastic rail joiners) that isolate sections of track from each other that means circuitry that can detect it also.
This is starting to get back to track DCC. (this is probably the only option I realistically have)
3. Machine vision camera for unique track marking ID, (not realistic or cheap)
4. A physical switch that is closed by physical contact with the train (i would rather just do track zone isolators methods, I don't want physical contact with the train)
5. You suggest something? The requirements are that the part on the track is passive(no power), and the parts on the train can be active(powered and logic communications)
I will put zone detection aside for now, like I did the sound, and start on accelerometer feedback from the caboose.
First I will try the 2d unit that is currently being sold on the parallax store. #28017 Mx2125
This means the caboose will now get a propeller, a WX wifi device, a 3.3v regulator, with the prop controlling the EOT also.
This also means the WX wifi caboose to WX wifi tender communications need to be coded, so this part of the project will take a few days to figure out.
I am not too sure on how to mount the accelerometer, the track bumps will be up and down and continuous.
The forward, stop, reverse motion will only be momentary and slightly fluctuate due to motor and grade changes.
The side to side motion of the cars rocking from uneven track will be continuous.
I think having it mounted so it detects the bumps in the track (up and down) and the rocking perpendicular to the track might be best.
I recall someone saying I wasn't descriptive and my discussions weren't long enough on my posts, so I have tried to increase my text effort(long winded-ness), how am I doing? ;P
I think that Kwinn is correct, I believe even the real railroads use trackside barcode sensors and barcodes to identify freight cars.
Jim.
IM CONVINCED! Now to find the proper equipment...
Here is the latest caboose code.
It shows the accelerometer on the caboose webpage, and lets you turn the EOT on or off.
The EOT is also controlled by the prop in the caboose.
The caboose has its own rail power pickups, parallax Wx wifi device, a prop, a memsic 2125 accelerometer,
a 3.3v regulator and 2 full wave rectifiers made out of 8 1n4001's (one per axle), an internal RGB led (for hearbeat if EOT is off) and the red EOT on the rear coupler.
(see attached image below)
I haven't coded Engine to Caboose communcations to get the accelerometer data to the engine for lack of movement Alarm and emergency stop.
For now I will monitor the web page for values that are normal for movement, and values that are normal for no movement.
the schematic for the new caboose circuit will be added to the main schematic.
I will keep the 555 timer EOT schematic with it in case others want a 555 eot instead.
I put it all on a breadboard, and stuck that inside the caboose for now, it fits exactly.
I didn't use a prop DIP because my supply of 55+ propeller dips was eliminated by badge wearin' crakhead psychopathic boozerz. (no really)
So I just used a prop I made that already had the 3.3v regulator, and wires,
The prop is the bizarre lookin star shape with a prop chip on top that was magnet wired together, got patience? (thanks Sally Hansen® and the beauty isle at walgreens, GET TO THE POINT!)
The zip file contains the v1.2 WX esp8266 firmware along with a linux (.sh) and windows (.bat) files needed to program it.
(this is just to update a factory WX wifi to v1.2 which has many enhanced features, it doesn't contain the engine or caboose files, you need to upload them to the WX device)
The zip also has the html for the engine which has been updated to show the current pwm on the webpage(every second updates automagically)(spin code was updated also)
And it has the html for the caboose to show the accelerometer output on the webpage(updates every 3 seconds automagically) and it has a switch for the EOT light.
Lets see what other kind of useless unimportant long winded toy garbage can i upload here... hmmm.
I suppose I will look into barcode scanning now. And continue to work on the accelerometer feedback from the caboose to the engine.
I am not doing the motor drive board current feedback using the PAB a2d because I don't have a PROPER axle sensor yet.
Updated schematic and this zip file will be put on the first post when I get the new schematic additions done.
L8r!
P.S. DO NOT HAVE THE WEBPAGE OPEN if you are (re)programming the prop, it will mess up the programming,
also DO NOT HAVE THE TELNET terminal open while programming, that will mess up the programming also.
These WX things have a limited amount of sockets available from what @"David Betz" has previously stated in my WXesp8266 fimware compile thread.
Don't loose a leg.
https://forums.parallax.com/discussion/download/132081/LostLeg.jpg
Or your life!
https://forums.parallax.com/discussion/download/132082/LostLife.jpg
https://forums.parallax.com/discussion/download/132083/DeRail.jpg
We all derail, its inevitable, what matters is the aftermath and how we clean it up, and change our ways,
many just leave the train wreck in place, due to arrogance, a lack of care, and a failure to even recognize any fault at all.
My fault with this derail wreck was I oiled the axles with drippy oil, instead of lithium grease,
the oil got on the tracks and made them too slick, the engine hit the switch with less than perfection and jumped the track.
Without re-reading the whole thread, and I do recall you mentioning using WiFi or Bluetooth. There is also the 433MHz/etc alternatives too. On another thread the RN42 is discussed and while $$ the current is ~50mA max which is good.
Now, for existing trains and tracks, DCC is likely used. New "your smart" trains can be added to the tracks without changing the existing track and trains. Your method of voltage recover will work just fine with them.
So what does your "smart" train(s) need?
A "smart transmitter" to control the "smart" trains. It can be any smart computer device with software. It just needs to know the addresses of the "smart" trains. Transmitter is obviously a transceiver but it is the master
The "Smart train(s)" need a compatible receiver (receiver is obviously a transceiver but it is the slave(s)).
* power recovery from the tracks - compatible with DCC but just recovers power - your basic circuit a number of posts back fulfills this requirement.
* position detection around the track - reading a barcode on the track would be the easiest way to go as it only requires barcodes to be placed around the tracks although they could require replacement due to UV and weather degradation. The alternative is the train has the barcode and scanners are placed around the track - more work as it has to be fitted and wired even if wireless as it will require power. Other ideas also given below.
* "smarts" inside the smart train - a micro with wireless (wifi/bluetooth/433MHz/etc) communications to the master controller.
Each train would need to be assigned a mac or similar. The same is needed for existing DCC trains anyway. The mac style is likely to be unique meaning trains do not need to be programmed each time they go onto a track.
Barcode Detection
It may be possible to also read the barcode from the side rather than under the track. This could mean that a sign with a barcode, similar to the station signs on the platform could be used. Much easier to place around the track?? Just need to standardise on height. This would be much easier than to have the barcode on the track - under the track would get interference from the sleepers.
Another option may be to use the sleepers as the barcode gap, and the area in between the sleepers to code a "0" or "1" by being black or white. Not sure how many bits you might get between the sleepers. A barcode doesn't actually need to be a real barcode, just a sequence of 0's and 1's to get an 'n' bit code.
I have noticed my Parallax WX wifi devices I use now (#32420) use lots of power.
The caps I have on the track voltage after the rectifier do very well in keeping the motor powered and the wifi device powered during serious power drops.
(I can put a paper towel on the track that is 4 inches wide and the motor plus tender will handle it) (i do this to clean the wheels, once in a while)
I have found supercaps are probably not worth the trouble, the many issues described in this thread...
https://forums.parallax.com/discussion/146613/supercap-application-question
I am going to try putting my supercap on the track voltage side for my caboose circuit, by stacking 2.7v caps, but their lifetime sucks, so using a very large cap like I use now is probably best.
Discussed below... timing, speed, start bit stop bit.. become factors.. laser scanner, done, and done?
Thats not a bad idea.
I would only need 4 bits, that would give me 16 different values, but this involved timing, speed requirements, etc..
Start bit, and a stop bit.. plus data bits... etc.. i think speed might be a factor here...
A diode laser barcode scanner would make this much easier?, laminated laser printed barcodes...?
Definitely not a cheap or small way to go.
$44.95
https://www.sparkfun.com/products/16441
I thought about using a ping perhaps and fill the space between the sleepers with material to make it the same height as the sleepers, or vice versa.
But the ping seems like its kinda wide.
But the laser ping might actually work and its hole out the bottom of the car would be small.
The minimum range is .78 inch, and g-scale wheel diameter is about 1.5 inch.
An issue might be any thing like a switch, or a lgb isolator piece of track.
However, objects could be put in between the track that rise to the same height as the track, which is far above the sleepers,
that would give clear distinction from the sleepers and between the sleepers.
It would still get close to what switches, crossovers, and other track intersections do though.
But a long piece of something the same height as the track would be distinct.
G-scale switches are about 1 foot in length, and some are even longer 1.5.
So any object that is used with laser ping would need to be even longer than any single object.
I would think piece of wood at the height of the track, which is 4 inches long (used as a start bit) and then notches cut out on the last few inches could be detected with the laser pin?
https://www.parallax.com/product/28041
The sparkfun laser scanner looks like it will fit into an HO boxcar (pointing down)
(my desire is to make all this also work in HO) its only 1inch wide or so, and 2 inch long(with the sparkfun pcb)
It looks like it can be removed from the sparkfun pcb and just have the ribbon cable connected
so that would help with mounting it in HO, it looks like the sparkfun pcb is screwed to it.
I also wonder if the mirrors of the sparkfun laser scanner would get damaged from rail shock, if that is even an issue with it.
I know shock is a big issue with handheld barcode scanners.
I won't even try to fit it all in N-scale, that is a nightmare. I have a large n-scale layout and I know that its VERY hard to work with.
I have a color pal but its required distance is too close.
For simplicity and cheap price, and I already have multiple IR sensors and emitters... I will test with a simple IR led and sensor.
I don't have the money for that laser scanner, or the laser ping.
My concern here is the brick and grass in between the sleepers...
I guess the only option I have is install a IR sensor and emitter and try it to see how the brick and grass and dirt and other materials are detected.
But then I get to deal with different sun intensities, different angles, night time, etc.
This shouldn't be this hard, lol, the IR method won here simply due to money. I will give that a try.
Take a look at the cheap line follower robot cars - a very simple circuit that can tell the difference between black and white which is all you are trying to do to read a barcode. Remember barcodes are really fine lines - you don't need them to be this fine and a larger bar can be read much simply.
I keep forgetting that the track is huge (ie not bedroom size). Why not try a GPS in the train - might be accurate enough. It won't tell you which track you're on when they are side by side, but might give you enough info.
There are DCC devices specifically for doing this.
One example: https://www.digikeijs.com/en/dr4088cs-16-channel-feedback-module-s88n.html
Another, with fancier features: https://www.digitrax.com/products/detection-signaling/bxp88/
The bar code idea is good though. Get one of those line follower modules (super cheap), then print some barcodes where the black and white areas are large (since your train will pass over pretty fast). Then mount the line follower module facing down under your loco, and stick the barcodes in the track between the rails.
You can even do this with an IR LED itself as the receiver so that each end uses only a single LED both for transmitter and receiver. I did this on a couple of products and implemented two-way serial communications over several meters.
btw, the code could be something as simple as a frequency or else a use a cheap sot-23 3 cent mcu to generate the code and carrier.
That could be possible I think, gps is 3 feet or so accurate, military gps is much more accurate, but encrypted,
but I kinda wanted to be HO compatible and even n if I can fit it.
I actually have a few of the bxp88's, and they do work well for current detection, but their transponding ability depends on the decoder you choose (do NOT use the sdxn136ps decoder if you want to do transponding, it mixes up its transponder with all other layout transponders regardless of the zone they are in. Its like a clown show, you don't know whos comin' or goin'.
Once my dcs240 blew up because I ran an engine from the main track to the programming track when the programming track switch was on,
it killed the entire command station. That was the end of my DCC experience, and since the bxp88's need it, those are useless also,
along with some DS64's. I may end up making my own versions of everything, since I know how they all work,
I just wont use loconet or the digitrax transponding system, I will make my own up.
The problem with zones is they require 1 wire per zone, that means I am running a bunch of outdoor wire, and its possible this may be the only way.
I am going to try other things first before I fall back on zone current detection.
I will look into that!
I will definetly have to look into trying that possibly with the line follower modules...
Like cluso99 says, I cannot/dont want to install powered things on or around the track, its all outdoors.
I am willing to have some limited exceptions like rr crossings, but I will need to outdoorproof them
So anything electronic must be on the train, the track can power things, but that means those things must also be taken apart and brought inside.
Ok, think about water, snow, wind, HAIL, 90 degree direct sun, etc, bugs, raccoons, cats, skunks... etc..
OUTDOOR!
Thanks for the PHOTON PLATFORM and PARTS, PARALLAX, the PROPELLER, makes PROTOTYPING with PHOTOS, PHUN!
I am not skill, I have no employable. DO NOT BELIEVE THE HYPE, only believe the everyday mundane edjumication.
That means I had to increase all the TVS devices to 20v, and also the activity board WX needs to be REV B or C, REV A only allows 15v max.
I have AWB rev A, so i guess we will see how long it lasts with the two diode vf drops between it and 18v track voltage.
My max draw through the first rectifier diodes is less than 1 amp, that means a vf of less than 1v (but there are two diodes in the full wave rectifier package)
and I have a 1n4001 just before the AWB, but that one will likely draw much less than 1amp
so I will be on the egde of max allowable voltage to the PWB rev A. I will probably be ok. (so far so good)
I have included the caboose code in the zip file on the first post and the schematics to include the caboose circuitry.
The caboose code also now includes a swinging lantern control, the webpage also has a switch for it.
I have included pause code between commands to the WX device because sometimes when running the POLL command
it interprets it as something to output to the telnet serial interface, which then shows the word POLL on your debug telnet terminal.
Kind of an odd bug...
I WAS using the command
ser.str(string("POLL:"))And I don't think I should be including the colon without a value after, not sure if it matters, butser.str(string("POLL"))works also, so I will do more testing to see if the problem still shows.The motor code was changed a bit to deal with pwm numbers higher than 100 or lower than 0, this is because the code I should probably do this differently, but it works with the checks...
I also combined the forward and reverse code so it reads easier.
I am trying to comment better, some comments were left over from copied code when the code was changed but the comment was not.
I may still have some comments that are incorrect, I will fix as I find them!
The first post has the updated schematic, and the zipped code.
With 2 or more WX wifi devices its highly recommended that any user get a dedicated wifi router that is not on the internet
to link all the devices and your webpage control method (tablet, pc, phone etc),
then the next revisions of code will work when I implement an emergency stop if the caboose's accelerometer detects no movement.
When you name the WX devices, my code will expect the names to be, "Engine" for the engine, and "Caboose" for the caboose.
The router needs to be able to properly deal with local DNS names for this to work, if you name your local domain something like RR.local,
Then you can use common names like engine.rr.local to access the config page or engine.rr.local/files/index.html to access the control page.
I haven't tested if the connect command in the WX module can use dns names or if it requires specific ip numbers, I hope it can do dns names.
Wireless communications instead of DCC sure does make this easier, no transponding, the wifi devices already have the ability to be uniquely named etc.
The protocols are already there for you.. Your wifi router basically becomes your command station to link it all.
Xvid video codec and Flac audio codec, avi format.
I also added m4v format for crapple users.
I still haven't purchased my grease so the tender wheels squeek.
The REAL wood makes the log car heavier, which prevents some derailments around curves from the heavier cars behind it.
Somebody stop MEH, im havin too much fun.
Now I need to find a G-scale log crane to modify with parallax servos, motor drive board, wx wifi, etc, then I can load the logs also.
THAT IS AWESOME.
I am trying out the WX examples in the SIMPLE TOOLS LEARN folder.
Learn\Examples\Network\WiFi\Prop to Prop via WX (Client).side
Learn\Examples\Network\WiFi\Prop to Prop via WX (Host).side
https://github.com/parallaxinc/Simple-Libraries/releases
I just changed the ip to my hosts dns name.
My caboose will be sending its accelerometer values to the engine in no time... EXCELLENT!
This also paves the way for the engine to detect its position on the track (with linescan or laser ping)
and then contact the railroad crossing prop to turn on the crossing lights, bell, and lower the arms. (once I make it all)
Whoever made these C examples did a great job providing many different examples, thank you! (parallax?)
For some reason my Client.side file couldn't find the "sscanAfterStr" function even though its in the library.
So I modified the Prop to Prop via WX (Client).side file to include that function inside the file its self.
I also slowed the whole thing down so I can snoop the tx and rx lines to get how it works and convert it to spin.
Once I have a spin example working it will be posted in my WX compile thread like the other examples.
Heres the modified Prop to Prop via WX (Client).c file.
/* Prop to Prop via WX (Client).c Sends TCP GET request to host, and displays values in responses. NOTE: The TCP message this page sends is very similar to what the browser sends in response to an update button click in: http://learn.parallax.com/tutorials/language/propeller-c/parallax-wx-wi-fi-module-prop-c/page-requests-info-propeller */ #include "simpletools.h" // Library includes #include "wifi.h" // IMPORTANT: Use the IP address for your host WX in both the hostIP // and request strings. char hostIP[] = "caboose.rr.local"; // Host IP address char request[] = // TCP GET request "GET /tpfm HTTP/1.1\r\n"\ "Host: caboose.rr.local\r\n"\ "Connection: keep-alive\r\n"\ "Accept: *" "/" "*\r\n\r\n"; int event, id, handle; // wifi_poll variables char tcp_str[256]; // TCP string int x = 0, y = 0; // Test values int sscanAfterStr(char *buffer, char *str, char *fmt, ...){ char *loc = strstr(buffer, str); loc += strlen(str); va_list args; va_start(args, fmt); int blocks = _doscanf(loc, fmt, args); va_end(args); return blocks; } int main() // Main function { wifi_start(31, 30, 115200, WX_ALL_COM); // Start wifi in other processor wifi_setBuffer(tcp_str, sizeof(tcp_str)); // Use tcp_str instead of default while(1) // Main loop { int tcpHandle = 0; // Poll for handle while(tcpHandle < 5) { tcpHandle = wifi_connect(hostIP, 80); // Try to open connection } // Send TCP request via connection handle wifi_print(TCP, tcpHandle, "%s", request); for(int n = 0; n < 100; n++) // Poll for response { wifi_poll(&event, &id, &handle); // Check event pause(5000); if(event == 'D') // If data received... { wifi_scan(TCP, tcpHandle, // Store data in tcp_str "%s", tcp_str); // Get values after x= and y= sscanAfterStr(tcp_str, "x=", "%d", &x); sscanAfterStr(tcp_str, "y=", "%d", &y); // Display values print("Client: x = %d, y = %d\r", x, y); // After processing x and y, preak out of the for... loop break; } } wifi_disconnect(tcpHandle); // Disconnect after exhcange // IMPORTANT: Frequency of requests should be less than max response // frequency. So, make sure to a pause here that's longer // than in host back end code. pause(5000); } }If it is not moving it will say on the telnet terminal connection.
No action or webpage feedback has been implemented yet to do anything with a lack of caboose movement.
It shows no movement if the accelerometer values are 0 or the change from the last value is less than 3. (absolute)
Much more is involved with the WX module when making a prop talk to a prop.
The code also commands the WX module to close all connections at startup (the prop might restart from lack of track connection
when lacking voltage props drop out before the wifi does. So I command all WX connections to stop at startup.