Why do they confuse it all by showing a sine wave? Then the scope signal was low level but I'm referring to the transponder signal, not the controller which I now understand it outputs "AC" as those continuous 1's and 0's. I will have to read up more but obviously the transponder can't do the same, can it?
Here are the rear images. Multiple images in case needed parts are dark or blurry.
Its hard to read any parts on those images, so i would need to setup a different camera and lighting and tripod if you need to be able to read the parts.
Or i can tell you. Parts are under the caps, and the various TO-220 parts also that the camera didn't capture at all or very well, and that flat beeper is also in the way, it can be removed but might destroy it, most of the traces I did for the programming circuit, never went to that spot.
There are lots of strange looking things in the schematic but I'm guessing once it's all complete it will be fine. For instance that choke in the schematic doesn't look right but looking at the component on the right of the board I see that it is a common-mode choke. What you always need to establish is the common (ground connection) and then take things from there. One way you can create a schematic is to place a library component on your schematic in the same place that matches the pcb. Then "wire up" the schematic the same way after which you can drag schematic components around and line them back up. Easier said than done, but hey, you've already told us you've got plenty of time on your hands!
There are lots of strange looking things in the schematic but I'm guessing once it's all complete it will be fine.
Yea, i just worked from the PA and PB lines out, I didn't place all components first.
Those chokes, choke me up when doing tracing, they act like direct connections.
Yea, im not even half way done on this thing and I might have made some mistakes, missing some traces, etc..
Its a slow process that bugs your eyes out, and makes your brain want to start seizures.
I will probably get it done in a few days, and correct some errors, like some of the choke continuity errors.
I accidentally connected some of the mosfets to each other in the schematic, when they in fact go to the choke first, i corrected a few already since posting the latest schematic.
Use a continuity tester to establish the common ground connections, and then the supply etc. You could mark each ground with a dot on the pcb as you probe it so that it is easier to read later. Or take a desaturated printout of the photo and mark that.
If one were to use modern chips, instead of discreet circuitry, couldn't this design be simplified a bit?
Like using an actual h-bridge package, (which has short protection, overload protection, over voltage protection, shoot through protection, etc.)
And same with sensing, using a current sense chip instead of all that discreet circuitry... etc...
It may be more expensive, but much more pleasant to build and repair if needed.?
And the same goes for the decoders? Use rectifier/regulator packages that have better protections built in the ic?
I think it would be worth the extra cost, simply because it would have prevented the total destruction of everything, (command station, motor decoder, and sound decoder) (thats already over 350$ in busted stuff)
If one were to use modern chips, instead of discreet circuitry, couldn't this design be simplified a bit?
Like using an actual h-bridge package, (which has short protection, overload protection, over voltage protection, shoot through protection, etc.)
And same with sensing, using a current sense chip instead of all that discreet circuitry... etc...
It may be more expensive, but much more pleasant to build and repair if needed.?
And the same goes for the decoders? Use packages that have protections?
I think it would be worth the extra cost, simply because it would have prevented the total destruction of everything, (command station, motor decoder, and sound decoder) (thats already over 350$ in busted stuff)
Yes probably. I'm just looking at the circuits from the MERG website.
I was looking at the command station schematic, and that "current sense" line going from the h-bridge ic to the pic...
I wonder is that used to read the dcc data FROM the decoder? I suspect NOT, that its for other use?
I wonder if they just program the decoders blind, or pre package it all in the pic firmware and not have any way to program/read the CV values.
The problem with their circuit schematics is they don't have round DOTS where the wires connect, to help determine if they just cross or in fact connect.
Id try to see if I could use something like this to current sense.
The ACS70331 is Allegro’s first integrated, high sensitivity, current sensor IC for <5 A current sensing applications.
It incorporates giant magneto-resistive (GMR) technology that is 25 times more sensitive than traditional Hall-effect sensors
to sense the magnetic field generated by the current flowing through the low resistance, integrated primary conductor.
The analog output provides a low noise high-speed signal, which is proportional to the current flowing through the primary.
The response time of the part is typically 535 ns.
The ACS70331 is offered in four factory-programmed sensitivity and offset levels to optimize performance over the desired current measurement range.
The differential configuration of the GMR elements, relative to the integrated current conductor,
provides significant rejection of stray magnetic fields, resulting in stable operation even in magnetically noisy environments.
The ACS70331 operates from a single 3.3 V power supply and is qualified over the full commercial temperature range of –40°C to 85°C.
It is offered in a low-profile space-saving surface mount QFN and SOIC packages.
I don’t think that driver is very good as it’s RDSon is 0.3ohm. Mosfets with a few milliohm are readily available in smt and don’t require heat sinking. Don’t know if there are H bridge devices tho?
There’s a half bridge driver so8 L6384E so maybe there’s a full bridge driver in a single package?
Saw a 65A IC sensor chip in dangerous prototypes at the beginning of the year. IIRC there were lower current ones.
I wouldn't have a problem if a prop based command station and decoders didn't conform to NMRA specs at first (at least when it comes to the variety of voltages for the different scales)
I would be fine with designing it for max values of +/- 16v and 10amp, that would put it in the acceptable range of most dcc equiptment.
If the data techniques were kept NMRA compliant (why not) then most retail decoders would probably work fine on the rail.
I went G-scale because I am tired of trying to shove stuff into a n-scale engine, plus I want to be able to make it with a proto board.
Some of these decoders available are insanely small, and even then they barely fit into nscale, its so hard to work with that,
and then you do get it in there, and it fries very fast due to heat or a lack of protection circuitry.
I bet you some dudes turned over their entire table after having their 8th n-scale decoder DIE on them, "IM OUT!"
I've had at least 4 sound/motor decoders die on me after a very short time.
They were the sdxn136ps decoders from digitrax.
Even if it dies within the first year, and digitrax offers free repair, the process of removing it again, ... only to have it die one day again?
Apparently you are not supposed to actually RUN your layout, its just a diorama.
when it took them 2 hours to connect it all and carefully route everything, finding the perfect spots for the decoder in the shell, and the capacitor.....
It wouldn't be hard at all to make a motor and sound decoder, since the prop can read wave files from a sd card, and play them to a simple ic AMP and still have great sound.
The various things the command station does and the decoders do, are HEAVY in advanced programming for things like 128 step speeds, silently driving the motor, simultaneous sounds output, etc..
The hardware design is probably 10% of the work involved compared to the software side.
I suppose there is one thing to say for a design that uses mostly discreet components, in 10 years, the parts will still basically be available.
The specialized IC's don't seem to have a long supplier life.
And as far as home hackers/makers/DIY, most do like discreet designs, they can use all the parts they've been collecting for 20 years.
From what I understand, right to repair, and the laws that protect Hayes manuals (complete tear down and documenting of cars).
Posting this pcb teardown and documentation is legal, due to the right to do product reviews, repair, and the like,,, am I right?
I am doing nothing with the firmware, nor will it be posted or disassembled, basically this circuit is useless without the firmware.
If I understand correctly, is encrypted and the encryption is custom to each chip. (so if i were to replace the pic, the firmware wouldn't work due to fuses not set?)
I don't want to step on any toes here, in posting this information due to my need for help with this repair.
In the meanwhile, I took a break from the analysis of the pcb.
I installed some LGB rail brush cleaners on my caboose, I had to trim a little bit of plastic to fit it in between the frame of the bachmann northwoods logger caboose.
It now fits perfectly, the spring loaded pads have up and down play still. I won't run with them all the time... just when needed.
I think they would have a hard time enforcing it on a $250 product for a single person. It would cost them more than $250 to write a legal letter and the damage they would do to their market would kill any future sales
Hobbyists can vote with their wallets, whereas farmers need the $M machines to survive so they can be held to ransom.
Schematics without dots are fine since a T-junction is a connection. Crossovers used to have the old-fashioned loop but you can just draw them straight-through cross-hairs fashion which means it does not connect.
Generating the track voltage and command data is easy enough and that DCC decoder circuit could be straight out of the 90's as are the L6202 drivers.
Is there an overall block diagram of the electronics used in a complete setup? I'm confused because I see CANbus and DMX etc. How is the transponder data detected?
Everything looks like it is overly complicated because of the reliance on 90's tech.
Once I've got an overall picture I think I can come up with a much simpler solution.
Peter,
It helps when you know what your looking for and what it's doing
The MERG website has kits with schematics - see the download section for the schematics. There are also PDFs that explain the DCC working, and there is a wiki too with some more explanation. Once you read it, it's not that difficult. Basically you are driving a differential output to switch an H bridge mosfet to drive the rails with ~12VDC-24VDC alternating (square wave) at ~116us/200us cycles where a cycle is a digital bit of data. It gets more complex for reading back responses as the train shorts the track to signal data, but that is a later addon.
You would need a deadband section to prevent shorting.
By removing the train programming on the isolated track, the circuit can start with...
1. Power Supply (eg 19V @ 4A from a laptop might do)
2. The Booster (this is the H bridge driver)
3. Controller (this could be a P2 initially with maybe a MOSFET H-bridge driver)
The controller would later be expanded to get info from the handheld controller devices (forget their title) once the basic system works.
It could be made modular, rather than all on the once pcb. This way, it could be expanded more easily.
Is there an overall block diagram of the electronics used in a complete setup? I'm confused because I see CANbus and DMX etc. How is the transponder data detected?
Everything looks like it is overly complicated because of the reliance on 90's tech.
Once I've got an overall picture I think I can come up with a much simpler solution.
Are you talking about the MERG.ORG equipment? I don't know about their transponder data tech.
I know that the digitrax setup uses special transponder receivers which have built in block detection. Like the bxp88.
But I do not recommend them because I have 4 and they all mess up transponding with their sdxn136ps motor/sound decoders. (i have 10, and ALL DO IT)
Transponding with those two products from them is completely pointless.
What good are they if you can select a fake loco (any random number not on your layout) in your throttle, and it will show up in the zone that you have a sdxn136ps located which isn't selected with your throttle.
And true locos in different zones will swap locations at random, totally useless.
I really don't like it when companies sell products that turn out to be true lemons, and then when you bring it up with them, they just give you the simplest answer, "did you install the transponding resistor" ?
A reply like that makes me literally want to visit their location, and throw the bxp88 through their front window, no i would never do it, but still.
I have noticed digitrax is a bit wak, they act like their loconet is some super secret info, so revolutionary that you must get their permission to use it. No, i'll just make my own. K thanks bye.
And they neglect the biggest software programmers for rail control, JMRI, and they don't even update their loconet information to include the new products or all the details about the loconet messages.
Just buy it and don't worry about all those loconet messages that can't be decoded, aren't in the manual, and aren't in their super secret loconet personal edition pdf.
This garbage is still dated 1997!!!!!!!! https://www.digitrax.com/static/apps/cms/media/documents/loconet/loconetpersonaledition.pdf
Thanks for the support on ALL the new products since then.. wtf.
And the same with their transponding....
They based it on the way programmers work, whats so revolutionary about that? nothing.
And clearly the moron patent office didn't know anything about dcc and dcc programming when they granted it.
I once asked them about the header on the sfx006 sound decoder, I needed to know the pinout, they refused to tell me and said its proprietary, my response was.
"Thanks for nothing, I just used a multimeter to find the ground and vcc supply so I could use the vcc supply to provide the cam sync wire with a less noisy source than the track, you might want to provide a wire for that purpose if you won't detail the header."
This is why I want to make or use an open source system, then it can be fixed instead of a cold stone wall of a reply when you say their stuff doesn't work as advertised at all.
I am not using this thread to hack at digitrax... I just have a large amount of their stuff and its pretty shoddy at best. And I wouldn't be even considering a whole new everything if it all just worked.
They have great PR and graphics and hype on their website, but when you get it in your hands, you just say, wtf.?
And you work on it for years and eventually realize its not you or the way you wired it or the way you ran your wires.
When you setup a test rig like this "Digitrax Transponding Bad1.jpg" and it still does it, you basically hit full stop.
Then, don't get me started on how the digitrax transponder, when turned on via the CV will completely screw up the programmer track, violating NMRA rules. What is that?
As you can see by the pictures, I dug pretty deep into getting down to the root of the problem, and it wasn't crosstalk or the layout wiring, if you look at the "Digitrax Transponding Bad1.jpg" You can clearly see all the wiring.
This site talks about transponding, and the DIGITRAX or RAILCOM methods.
Digitrax transponding uses a "key on the bit cycle of dcc on the tracks in their bxp88 transponder zone devices.
You will not see this key on their command stations dcc output, you must have a bxp88 or bdl168 specialized transponder devices.
It looks like a rail profile at the end of the scope shot gif.
A "notch" in the dcc data, and on the next bit swing of the dcc data, a "notch" removed in the dcc data
The blue line is with a transponding decoder, the red line is a zone without a decoder.
When you zoom up on one of them, you can see its just a mini version of dcc rail data, shoved into the center of a single bit of dcc rail data.
But it clearly doesn't work properly for them. So mabee avoid that method, and go with the railcom or a whole new system since they both want to play patent wars.
That must have been before everyone realized that open source is adopted faster, widely,
and makes companies more money, than all of this royalty patent "limit you", gimme my mo0ney beeeeetch.
The reason their system fails to work, is because the 101 transponder reply from the decoder is THE SAME FOR ALL DECODERS.
So I would suggest that if an open source transponder system is implemented,
do it like the NMRA DCC programmers, ..... instead of the digitrax method of the same reply for all transponders.
Instead of the system saying, "hey loco 533, where are you" and the loco replies, 101, the digitrax way.
Then the system says again, "hey loco 844, where are you" and that different loco also replies, 101, the digitrax way.
Thats ripe for confusing them all up in a jumble, even though the locos are in different zones, exactly the problem I was having, the digitrax way.
Instead tell the decoders that they have a designated window of reply, and assign all decoders in the system with a different window of reply.
So, once a user programs a decoder, let the user choose a "slot" to let the decoder short the track (like programming replies do), each slot is X many bits away from the beginning of the DCC packet, etc. (this would be a new CV type)
A system like that would have a limited amount of slots, but enough to be fully effective.
A transponder message that is a reduced bit, hashed from the locos id, or something.
Have it reply something fairly unique based on a hash of its loco id, but still smaller to fit in designated windows, and in an assigned "slot" in the total dcc packet stream, this would be set up, during decoder programming, in a new CV.
I suppose if you made the decoder, it can be any CV you want, that doesn't conflict with the NMRA base cv's.
With very fast current sensors these days, the fast propeller chips, you can shove quite a "bit" (intended pun) into a single DCC bit,
and our fast propeller chips can be put into decoders to send out that fast precise unique bit stream data, similar to how programmers do it.
We can now take advantage of super precise and fast current sensors, and microcontrollers.
Like the ACS70331, Allegro’s first integrated, high sensitivity, current sensor IC for <5 A current sensing applications.
The DCC NMRA programmers have NMRA limits on how much current they should be pulling for replies,
so perhaps it should be followed to conform, this means a current sensor that has even less max amperage.
MIT License
Copyright (c) [2020] [Clock Loop]
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
"This is defined by the decoder providing an increased load on the programming track, of at least 60mA for 6mS.
One method is to apply power to the motor, or a similar load connected to the decoder.
Many decoders apply a short burst of power to the motor, causing the locomotive to lurch forward. "
"Direct Mode is similar to Paged Mode, except when querying a decoder Direct mode asks "Does Bit 'X' of CVx = 1?"
It is faster, as it can read an eight bit CV with 8 queries (1, 2, 4, 8, 16, 32, 64,128) instead of a possible 255 reads required by Paged Mode.
It can then calculate from those responses what the content of CVx is.
In the worst case the command station will have to wait for 8 timeouts to occur, or 9 to determine no reply.
The command station will then follow up with a full byte verification to ensure no mistakes occurred.
This mode can be 50 times faster than the other methods available.
With modern decoders, such as the ESU LokSound's 100,000 plus CVs, this makes a difference. "
@"Clock Loop" have you considered using wireless communication?
I have a bunch of Lego Train track and cars. After seeing your description of DCC I decided it would probably be easier to just use a little nRF24 module in each engine. I've used these modules in several projects and they're very inexpensive now.
Do you know of any good reasons not to go wireless?
A big reason why people do rail power and data, is because wireless WAS expensive, but another reason could be to automate your track with JMRI, by having "zones" so the automation knows where each train is.
However, this could be done with wireless too, in larger locomotives, wireless is a real possibility, ( HO and bigger)
Nscale, no way, unless you want many micro wires running from your engine to another boxcar behind it.
I am doing g-scale, so I would be ok with wireless, and polymer batteries, or just straight DC on the tracks for power only.
And wireless could make zoning even easier, by simply having a series of powerful neodymium track magnets close together or something that closed a reed switch in a unique pattern, to signal what zone you are in?
Or some form of optical indicator for the zone?
Wait, an RFID tag could be used in combination with a wireless system to do zoning. and also for crossings, and the like)
PARALLAX SELLS THEM...
Lets see, time to go to the parallax store and buy a bunch of tags and a few readers.
I haven't thought alot about how to do a wireless DCC system with zone detection... ESP's are cheap enough to make it easy.
I guess then it would be just a matter of coming up with some kinda wireless dcc standard similar to NMRA?
And even a meshnet system, since that is all the hype these days...
That would eliminate all the dcc garbage, current sensing, complicated circuitry... yea im all for that. forget this pile of patented garbage, im totally game.
@"Clock Loop" have you considered using wireless communication?
I have a bunch of Lego Train track and cars. After seeing your description of DCC I decided it would probably be easier to just use a little nRF24 module in each engine. I've used these modules in several projects and they're very inexpensive now.
Do you know of any good reasons not to go wireless?
Part of the system is so you can tell which section of track the train is in. Wireless cannot do this.
The problem now is trying to be backward compatible. Otherwise, putting a carrier on top of DC for the communications would probably be easier these days.
Part of the system is so you can tell which section of track the train is in. Wireless cannot do this.
Like I mentioned, a rfid tag system would make adding "zones" to your layout as cheap as a pair of tags, one for the entry of the zone, and one for the exit,
Repeat for every zone, and enjoy having 100 zones on your layout for the price of less than 6$ per zone. (two tags) https://www.parallax.com/product/28445
The limit being how close two tags can be together before the reader mixes them up. So Every 1.5inches?
(entry of a tag, exit of a tag, detection of two tags at once would mean you were in the middle of them etc)
Im gonna do this now. Forget this DCC track mess.
https://www.parallax.com/product/28440
"Designed in cooperation with Grand Idea Studio ,
the Parallax Radio Frequency Identification (RFID) Read/Write Module provides a low-cost solution to read and write passive RFID transponder tags up to 3 inches away.
The RFID transponder tags provide a unique serial number and can store up to 116... "
3 inches is plenty of room. for under the rail, and in the car.
You would only need the reader in the engine where the wireless is.
Unless you want other cars to activate on specific tags.
And if you wanted end of train detection, then you would need a reader and wireless device in that end car also. (caboose) or the car with the EOT (end of train) light.
Even large G scale engines only sit about 1 inch above the track, then add an inch for the plastic floor of the engine, and put your reader inside,
at about 2.5 inches away from the tag, on the bottom side of g-scale track, under the ties, I just measured it, and I think it would work great.
For smaller scales that can't fit the rfid reader, would it be possible to make a smaller reader that had a LONG antenna instead of a square one (so it would fit into a HO boxcar or something.
Or a smaller reader with simply shorter range? Or a reader with an antenna that can be made flat, smaller and placeable like a sticker, so you can stick it to the underside of the engine
, you just route the wires to the inside of the engine where the readers logic is located.
Hey parallax, lets get started on a RFID and WIRELESS model railroad control system. You have motor controllers right?
Build for g-scale, and then SCALE (pun intended) it down to HO, and possibly N?
(N would be pretty hard, but the rfid detection distance is like 1/4 inch so why couldn't the antenna and electrics be reduced?)
Build the rfid reader into the decoder. I see two small chips on that RFID reader thing. Can the antenna be folded on flex pcb? Or multiple pcb's stacked?
Could RFID readers be made to repeatedly check for the tags presence? (multiple times a second?) Instead of just the initial detection?
This would reduce or eliminate any detection failures?
I'm unsure if the rails might interfere with RFID. And they will be between the RFID tag and the sensor.
Remember, the rails are switching voltages at current, so there will necessarily be EMI being radiated.
I'm unsure if the rails might interfere with RFID. And they will be between the RFID tag and the sensor.
Remember, the rails are switching voltages at current, so there will necessarily be EMI being radiated.
Would that be an issue if the rails just carried a steady DC supply say at 16 volts, like the old style layouts, since the ESP8266 or other wireless is where the comms happen?
Yea, I didn't like the whole potential of my dcc layout generating a hella amount of rf noise, and then add G-scale layout in your backyard, and possibly make the local military base come for a visit?
Hey neighbor, mind if I run my railway and totally trash your HDTV or RADIO hobby?
My BLACK BOX audio sequencer and fx device on these forums, actually caused my friends HDTV reception to get completely killed when it was running.
He was watching the "game" and bam, completely dead signal, comes to me and says, are you doing something to interrupt the TV?
I thought, NO WAY? I turned it off, and the game comes back on. Time to get a metal enclosure for the Black Box. HA!
Comments
I can setup a better cam, lighting, tripod, etc. if you need, that will take me some extra time.
The front. Multiple images in case needed parts are dark or blurry.
Its hard to read any parts on those images, so i would need to setup a different camera and lighting and tripod if you need to be able to read the parts.
Or i can tell you. Parts are under the caps, and the various TO-220 parts also that the camera didn't capture at all or very well, and that flat beeper is also in the way, it can be removed but might destroy it, most of the traces I did for the programming circuit, never went to that spot.
And i can't turn off my signature for specific posts anymore. All off or all on huh?
Yea, i just worked from the PA and PB lines out, I didn't place all components first.
Those chokes, choke me up when doing tracing, they act like direct connections.
Yea, im not even half way done on this thing and I might have made some mistakes, missing some traces, etc..
Its a slow process that bugs your eyes out, and makes your brain want to start seizures.
I will probably get it done in a few days, and correct some errors, like some of the choke continuity errors.
I accidentally connected some of the mosfets to each other in the schematic, when they in fact go to the choke first, i corrected a few already since posting the latest schematic.
This board has a bajillion parts.. lol
This could be useful to cut and reverse the sections.
Also, I’m expecting that the AC in will be rectified to DC for subsequent use with the mosfet H drivers. Just going back to check your schematics now.
Like using an actual h-bridge package, (which has short protection, overload protection, over voltage protection, shoot through protection, etc.)
And same with sensing, using a current sense chip instead of all that discreet circuitry... etc...
It may be more expensive, but much more pleasant to build and repair if needed.?
And the same goes for the decoders? Use rectifier/regulator packages that have better protections built in the ic?
I think it would be worth the extra cost, simply because it would have prevented the total destruction of everything, (command station, motor decoder, and sound decoder) (thats already over 350$ in busted stuff)
Yea! The merg command station uses this for its h-bridge!
https://www.st.com/resource/en/datasheet/l6202.pdf
But this part is only 5 amp at best, and I think i'd be more confortable with a 10A h-bridge... plus this part isn't available, at least at digikey.
I wonder is that used to read the dcc data FROM the decoder? I suspect NOT, that its for other use?
https://www.merg.org.uk/merg_resources/dcc/download/cbus-dcc/CANcmd/CANcmd_sch.pdf
Im not sure if I see a way in the decoder circuit to send data to the rail, by shorting it.
https://www.merg.org.uk/merg_resources/dcc/download/decod10b.pdf
I wonder if they just program the decoders blind, or pre package it all in the pic firmware and not have any way to program/read the CV values.
The problem with their circuit schematics is they don't have round DOTS where the wires connect, to help determine if they just cross or in fact connect.
https://www.allegromicro.com/en/products/sense/current-sensor-ics/zero-to-fifty-amp-integrated-conductor-sensor-ics/acs70331
Digikey only offers the part in QFN packages ($1.87) when ordering cut tape, the soic package is not available in quanities less than 6000,
There’s a half bridge driver so8 L6384E so maybe there’s a full bridge driver in a single package?
Saw a 65A IC sensor chip in dangerous prototypes at the beginning of the year. IIRC there were lower current ones.
I would be fine with designing it for max values of +/- 16v and 10amp, that would put it in the acceptable range of most dcc equiptment.
If the data techniques were kept NMRA compliant (why not) then most retail decoders would probably work fine on the rail.
I went G-scale because I am tired of trying to shove stuff into a n-scale engine, plus I want to be able to make it with a proto board.
Some of these decoders available are insanely small, and even then they barely fit into nscale, its so hard to work with that,
and then you do get it in there, and it fries very fast due to heat or a lack of protection circuitry.
I bet you some dudes turned over their entire table after having their 8th n-scale decoder DIE on them, "IM OUT!"
I've had at least 4 sound/motor decoders die on me after a very short time.
They were the sdxn136ps decoders from digitrax.
Even if it dies within the first year, and digitrax offers free repair, the process of removing it again, ... only to have it die one day again?
Apparently you are not supposed to actually RUN your layout, its just a diorama.
when it took them 2 hours to connect it all and carefully route everything, finding the perfect spots for the decoder in the shell, and the capacitor.....
It wouldn't be hard at all to make a motor and sound decoder, since the prop can read wave files from a sd card, and play them to a simple ic AMP and still have great sound.
The various things the command station does and the decoders do, are HEAVY in advanced programming for things like 128 step speeds, silently driving the motor, simultaneous sounds output, etc..
The hardware design is probably 10% of the work involved compared to the software side.
The specialized IC's don't seem to have a long supplier life.
And as far as home hackers/makers/DIY, most do like discreet designs, they can use all the parts they've been collecting for 20 years.
Posting this pcb teardown and documentation is legal, due to the right to do product reviews, repair, and the like,,, am I right?
I am doing nothing with the firmware, nor will it be posted or disassembled, basically this circuit is useless without the firmware.
If I understand correctly, is encrypted and the encryption is custom to each chip. (so if i were to replace the pic, the firmware wouldn't work due to fuses not set?)
I don't want to step on any toes here, in posting this information due to my need for help with this repair.
In the meanwhile, I took a break from the analysis of the pcb.
I installed some LGB rail brush cleaners on my caboose, I had to trim a little bit of plastic to fit it in between the frame of the bachmann northwoods logger caboose.
It now fits perfectly, the spring loaded pads have up and down play still. I won't run with them all the time... just when needed.
G-scale is much easier to work with.
Hobbyists can vote with their wallets, whereas farmers need the $M machines to survive so they can be held to ransom.
Generating the track voltage and command data is easy enough and that DCC decoder circuit could be straight out of the 90's as are the L6202 drivers.
Is there an overall block diagram of the electronics used in a complete setup? I'm confused because I see CANbus and DMX etc. How is the transponder data detected?
Everything looks like it is overly complicated because of the reliance on 90's tech.
Once I've got an overall picture I think I can come up with a much simpler solution.
It helps when you know what your looking for and what it's doing
The MERG website has kits with schematics - see the download section for the schematics. There are also PDFs that explain the DCC working, and there is a wiki too with some more explanation. Once you read it, it's not that difficult. Basically you are driving a differential output to switch an H bridge mosfet to drive the rails with ~12VDC-24VDC alternating (square wave) at ~116us/200us cycles where a cycle is a digital bit of data. It gets more complex for reading back responses as the train shorts the track to signal data, but that is a later addon.
You would need a deadband section to prevent shorting.
By removing the train programming on the isolated track, the circuit can start with...
1. Power Supply (eg 19V @ 4A from a laptop might do)
2. The Booster (this is the H bridge driver)
3. Controller (this could be a P2 initially with maybe a MOSFET H-bridge driver)
The controller would later be expanded to get info from the handheld controller devices (forget their title) once the basic system works.
It could be made modular, rather than all on the once pcb. This way, it could be expanded more easily.
Are you talking about the MERG.ORG equipment? I don't know about their transponder data tech.
I know that the digitrax setup uses special transponder receivers which have built in block detection. Like the bxp88.
But I do not recommend them because I have 4 and they all mess up transponding with their sdxn136ps motor/sound decoders. (i have 10, and ALL DO IT)
Transponding with those two products from them is completely pointless.
What good are they if you can select a fake loco (any random number not on your layout) in your throttle, and it will show up in the zone that you have a sdxn136ps located which isn't selected with your throttle.
And true locos in different zones will swap locations at random, totally useless.
I really don't like it when companies sell products that turn out to be true lemons, and then when you bring it up with them, they just give you the simplest answer, "did you install the transponding resistor" ?
A reply like that makes me literally want to visit their location, and throw the bxp88 through their front window, no i would never do it, but still.
I have noticed digitrax is a bit wak, they act like their loconet is some super secret info, so revolutionary that you must get their permission to use it. No, i'll just make my own. K thanks bye.
And they neglect the biggest software programmers for rail control, JMRI, and they don't even update their loconet information to include the new products or all the details about the loconet messages.
Just buy it and don't worry about all those loconet messages that can't be decoded, aren't in the manual, and aren't in their super secret loconet personal edition pdf.
This garbage is still dated 1997!!!!!!!! https://www.digitrax.com/static/apps/cms/media/documents/loconet/loconetpersonaledition.pdf
Thanks for the support on ALL the new products since then.. wtf.
And the same with their transponding....
They based it on the way programmers work, whats so revolutionary about that? nothing.
And clearly the moron patent office didn't know anything about dcc and dcc programming when they granted it.
I once asked them about the header on the sfx006 sound decoder, I needed to know the pinout, they refused to tell me and said its proprietary, my response was.
"Thanks for nothing, I just used a multimeter to find the ground and vcc supply so I could use the vcc supply to provide the cam sync wire with a less noisy source than the track, you might want to provide a wire for that purpose if you won't detail the header."
This is why I want to make or use an open source system, then it can be fixed instead of a cold stone wall of a reply when you say their stuff doesn't work as advertised at all.
I am not using this thread to hack at digitrax... I just have a large amount of their stuff and its pretty shoddy at best. And I wouldn't be even considering a whole new everything if it all just worked.
They have great PR and graphics and hype on their website, but when you get it in your hands, you just say, wtf.?
And you work on it for years and eventually realize its not you or the way you wired it or the way you ran your wires.
When you setup a test rig like this "Digitrax Transponding Bad1.jpg" and it still does it, you basically hit full stop.
Then, don't get me started on how the digitrax transponder, when turned on via the CV will completely screw up the programmer track, violating NMRA rules. What is that?
As you can see by the pictures, I dug pretty deep into getting down to the root of the problem, and it wasn't crosstalk or the layout wiring, if you look at the "Digitrax Transponding Bad1.jpg" You can clearly see all the wiring.
This site talks about transponding, and the DIGITRAX or RAILCOM methods.
RAILCOM: https://dccwiki.com/Term:RailCom
DIGITRAX: https://dccwiki.com/Transponding
You will not see this key on their command stations dcc output, you must have a bxp88 or bdl168 specialized transponder devices.
It looks like a rail profile at the end of the scope shot gif.
A "notch" in the dcc data, and on the next bit swing of the dcc data, a "notch" removed in the dcc data
The blue line is with a transponding decoder, the red line is a zone without a decoder.
When you zoom up on one of them, you can see its just a mini version of dcc rail data, shoved into the center of a single bit of dcc rail data.
But it clearly doesn't work properly for them. So mabee avoid that method, and go with the railcom or a whole new system since they both want to play patent wars.
That must have been before everyone realized that open source is adopted faster, widely,
and makes companies more money, than all of this royalty patent "limit you", gimme my mo0ney beeeeetch.
The reason their system fails to work, is because the 101 transponder reply from the decoder is THE SAME FOR ALL DECODERS.
do it like the NMRA DCC programmers, ..... instead of the digitrax method of the same reply for all transponders.
Instead of the system saying, "hey loco 533, where are you" and the loco replies, 101, the digitrax way.
Then the system says again, "hey loco 844, where are you" and that different loco also replies, 101, the digitrax way.
Thats ripe for confusing them all up in a jumble, even though the locos are in different zones, exactly the problem I was having, the digitrax way.
You can read about how decoders acknowledge the data they get...
https://dccwiki.com/Decoder_Programming
"This is defined by the decoder providing an increased load on the programming track, of at least 60mA for 6mS.
One method is to apply power to the motor, or a similar load connected to the decoder.
Many decoders apply a short burst of power to the motor, causing the locomotive to lurch forward. "
https://dccwiki.com/Decoder_Programming/Service_Programming_Modes
"Reading CVs in Direct Mode"
"Direct Mode is similar to Paged Mode, except when querying a decoder Direct mode asks "Does Bit 'X' of CVx = 1?"
It is faster, as it can read an eight bit CV with 8 queries (1, 2, 4, 8, 16, 32, 64,128) instead of a possible 255 reads required by Paged Mode.
It can then calculate from those responses what the content of CVx is.
In the worst case the command station will have to wait for 8 timeouts to occur, or 9 to determine no reply.
The command station will then follow up with a full byte verification to ensure no mistakes occurred.
This mode can be 50 times faster than the other methods available.
With modern decoders, such as the ESU LokSound's 100,000 plus CVs, this makes a difference. "
I have a bunch of Lego Train track and cars. After seeing your description of DCC I decided it would probably be easier to just use a little nRF24 module in each engine. I've used these modules in several projects and they're very inexpensive now.
Do you know of any good reasons not to go wireless?
However, this could be done with wireless too, in larger locomotives, wireless is a real possibility, ( HO and bigger)
Nscale, no way, unless you want many micro wires running from your engine to another boxcar behind it.
I am doing g-scale, so I would be ok with wireless, and polymer batteries, or just straight DC on the tracks for power only.
And wireless could make zoning even easier, by simply having a series of powerful neodymium track magnets close together or something that closed a reed switch in a unique pattern, to signal what zone you are in?
Or some form of optical indicator for the zone?
Wait, an RFID tag could be used in combination with a wireless system to do zoning. and also for crossings, and the like)
PARALLAX SELLS THEM...
Lets see, time to go to the parallax store and buy a bunch of tags and a few readers.
I haven't thought alot about how to do a wireless DCC system with zone detection... ESP's are cheap enough to make it easy.
I guess then it would be just a matter of coming up with some kinda wireless dcc standard similar to NMRA?
And even a meshnet system, since that is all the hype these days...
That would eliminate all the dcc garbage, current sensing, complicated circuitry... yea im all for that. forget this pile of patented garbage, im totally game.
The problem now is trying to be backward compatible. Otherwise, putting a carrier on top of DC for the communications would probably be easier these days.
Like I mentioned, a rfid tag system would make adding "zones" to your layout as cheap as a pair of tags, one for the entry of the zone, and one for the exit,
Repeat for every zone, and enjoy having 100 zones on your layout for the price of less than 6$ per zone. (two tags)
https://www.parallax.com/product/28445
The limit being how close two tags can be together before the reader mixes them up. So Every 1.5inches?
(entry of a tag, exit of a tag, detection of two tags at once would mean you were in the middle of them etc)
Im gonna do this now. Forget this DCC track mess.
https://www.parallax.com/product/28440
"Designed in cooperation with Grand Idea Studio ,
the Parallax Radio Frequency Identification (RFID) Read/Write Module provides a low-cost solution to read and write passive RFID transponder tags up to 3 inches away.
The RFID transponder tags provide a unique serial number and can store up to 116... "
3 inches is plenty of room. for under the rail, and in the car.
You would only need the reader in the engine where the wireless is.
Unless you want other cars to activate on specific tags.
And if you wanted end of train detection, then you would need a reader and wireless device in that end car also. (caboose) or the car with the EOT (end of train) light.
Even large G scale engines only sit about 1 inch above the track, then add an inch for the plastic floor of the engine, and put your reader inside,
at about 2.5 inches away from the tag, on the bottom side of g-scale track, under the ties, I just measured it, and I think it would work great.
For smaller scales that can't fit the rfid reader, would it be possible to make a smaller reader that had a LONG antenna instead of a square one (so it would fit into a HO boxcar or something.
Or a smaller reader with simply shorter range? Or a reader with an antenna that can be made flat, smaller and placeable like a sticker, so you can stick it to the underside of the engine
, you just route the wires to the inside of the engine where the readers logic is located.
Hey parallax, lets get started on a RFID and WIRELESS model railroad control system. You have motor controllers right?
Build for g-scale, and then SCALE (pun intended) it down to HO, and possibly N?
(N would be pretty hard, but the rfid detection distance is like 1/4 inch so why couldn't the antenna and electrics be reduced?)
Build the rfid reader into the decoder. I see two small chips on that RFID reader thing. Can the antenna be folded on flex pcb? Or multiple pcb's stacked?
https://www.digikey.com/en/blog/the-evolution-of-model-railroading-as-proxy-for-the-electronics-industry
These guys put tags on the car/engine on the smaller scales, this gets expensive, you need 2 readers per zone.
http://www.pcrnmra.org/pcr/clinics/RFID-in-Model-Railroading-20130123.pdf
http://www.qtutrains.com/RFID.html
Could RFID readers be made to repeatedly check for the tags presence? (multiple times a second?) Instead of just the initial detection?
This would reduce or eliminate any detection failures?
Remember, the rails are switching voltages at current, so there will necessarily be EMI being radiated.
Would that be an issue if the rails just carried a steady DC supply say at 16 volts, like the old style layouts, since the ESP8266 or other wireless is where the comms happen?
Yea, I didn't like the whole potential of my dcc layout generating a hella amount of rf noise, and then add G-scale layout in your backyard, and possibly make the local military base come for a visit?
Hey neighbor, mind if I run my railway and totally trash your HDTV or RADIO hobby?
My BLACK BOX audio sequencer and fx device on these forums, actually caused my friends HDTV reception to get completely killed when it was running.
He was watching the "game" and bam, completely dead signal, comes to me and says, are you doing something to interrupt the TV?
I thought, NO WAY? I turned it off, and the game comes back on. Time to get a metal enclosure for the Black Box. HA!