Welcome to the Parallax Discussion Forums, sign-up to participate.
Peter Jakacki wrote: »
There are lots of strange looking things in the schematic but I'm guessing once it's all complete it will be fine.
Clock Loop wrote: »
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)
Cluso99 wrote: »
Yes probably. I'm just looking at the circuits from the MERG website.
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.
Peter Jakacki wrote: »
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.
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.
Copyright (c)  [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
Duane Degn wrote: »
@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?
Cluso99 wrote: »
Part of the system is so you can tell which section of track the train is in. Wireless cannot do this.
Cluso99 wrote: »
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.