reading bar code from the bottom of model train

Go To Last Post
25 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is a project I probably have time for in a few years time, but I kind of like to already have some thoughts about it ;-)

The project will be a model train + track (of course) with fully automated central train control. For that I need the train control to know where every trains is physically located on the track.

I have weighed some alternatives and tend to favour a system that consists of "substations" detecting trains along the track. These can probably consist of attiny's, probably 861's, I'll see when I get there... The substations will be connected to the central control, probably using i2c or similar.

They will have an IR led and IR photodiode mounted between the rails, looking up and the train will have a bar code on the bottom side. If I choose the train id's clever, I will be able to distinguish the direction the train is moving in, as well, and maybe even the speed (but that's less important).

Has anyone ever tried something similar? Ideas, hints? I think I can make up the software, but it will be a tricky task, if the code is to be read at various speeds.

I have also considered:
- light barrier, simple to implement but no ID
- rfid, simple but way to expensive
- bluetooth, same
- frequency modulated ir from the train, no direction information, simple though
- classic block occupation detection (measure current or resistance between rails), simple but no ID and no direction information

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice ideas :)

Problem with barcode reading will be the variation in distance of the locomotive- and the individual wagon-floors. Because you need proper focus. Using a laser could solve that for the light transmitter but for the receiver it's harder.

How about RFID ? Tags (125kHz) cost around € 1,- and a reader can be home-made. Ossi (Martin Ossmann) told about that in one of his seminars on Elektor.

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tricia, and Ulyana. You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Having given it some more thought: barcode is feasible, if you stick to locomotives only and can assure the distance between barcode label and the detector is the same for each of your locomotives. Not Märklin I presume ? Fleischmann ?

Edit: this is attractive !
Just € 0,46 :!:

Edit2: not the best performance at a few mm's distance, but it will work if you can accept a slower data rate
See http://www.alldatasheet.com/data...

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tricia, and Ulyana. You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am probably wrong, but I seem to notice that the BART (San Francisco Bay are Rapid transit.) may have bar codes or OCR identifiers on the sides of the cars. This is 1950 technology which went online in the 1970s. This same technology is used for routing bank checks and is actually extremely reliable.

There are sensors in boxes that can be seen on the side of track which can detect when a given train crosses a specific section of track. When it rains these go haywire and the system has to run manually. It may be that a lot of the overnight maintenance is keeping these sensors cleaned and aligned.

Most likely the sensors report to some 50s/60s era big board. (with more recent hacks to provided updated information.) In theory the trains can (and sometimes do) drive themselves with no one in the cab.

BART is also run like a model railroad, just one that is like 1.2 scale (BART is wide gauge.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes. Most attempts to automate a train layout fail because they don't know where the trains are.

I think you could make barcodes on the bottom work with a laser to illuminate, as long as you could get a tight beam. The detector wouldn't need to be focused if the laser is tight enough to illuminate the dark light dark.

Of course, then you have to decode the bars. Does somebody have code for that?

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd second the RFID route. All the hard work has been done and you get a nice serial string when the train passes over. No direction or speed info though, but you could infer that from previous scan points.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I like the frequency modulated IR LED concept.

Pick up power from the tracks and flash the led mounted facing downwards.

The sensor is aimed upwards.

For typical model train speeds and a several centimeter dispersion cone it should be easy to detect the flashing IR LED and measure its frequency.

Freq is 1.0 KHz, 1.1 KHz, 1.2KHz...

One can have lots of small transmitters and receivers and not run out of ID frequencies.

For direction info one could even place two IR LEDs on each engine, one at its front, one at its rear. One small PCB drives them both. The front is always X KHz, the rear is X + 0.1 KHz. The PC analyzing the data then looks to see if the lower or higher frequency of the pair came first.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice thoughts DocJC. I've been a few days without any internet connectivity (stupid providers...) and in the meantime I also came to the conclusion that a pulsed IR led would be much simpler than the bar code reader.

Also I didn't realise that the beam lighting the bar code would need to be focussed. I was thinking of an ir photo diode being wrapped inside a black tube, I am not sure if that would give enough SNR though.

Also nice idea to implement dual id's on one train. This should be feasable in costs as well (2 ir led + oscillators per train, plus one microcontroller + 2 ir photodiodes per block, sounds reasonable...)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Plons wrote:

How about RFID ? Tags (125kHz) cost around € 1,-

Where did you find these? In low quantities? I know only of 5 euro's a piece...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Torby wrote:
Of course, then you have to decode the bars. Does somebody have code for that?

I have found none whatsoever on the web (bar code decoder for microcontrollers).

On the other hand, I think it can be done, if you keep things real simple. Not like QR ;-) The code would need to start with a unique tag that would signal to the controller a real code is coming (and not just some sort of noise). This tag should be recognisable at all possible speeds.

Then a series of synchronising tokens should follow, allowing the controller set it's internal clock to the train's real speed.

Then the data can follow, maybe it should be repeated, it might not get read correctly in all cases and a crc (so at least you know the data IS faulty).

The complete structure including data might be mirrored to make it readable in both directions.

The hardest parts are imho:
- the unique identifier that works on all speeds
- determine where the sync tokens stop and the data begins, the first sync tokens are probably not read in time, so you never now how many still folllow.

Somebody already came with the idea of two parallel "tracks", on of them being a "clock" pattern (1/0/1/0/etc.) and the other the data. Simpler, but still complicated.

So yes, with an ir-fm things will probably be much simpler.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

eriksl wrote:
Plons wrote:

How about RFID ? Tags (125kHz) cost around € 1,-

Where did you find these? In low quantities? I know only of 5 euro's a piece...

Cannot find the invoice ....
It was an ebay seller, Vincent Lau. I purchased 20 or so, in 2011. That's all I can trace back.

How about the IR bar reader, the samenkopen.net link I posted ?

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tricia, and Ulyana. You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Has anyone ever tried something similar? Ideas, hints? I think I can make up the software, but it will be a tricky task, if the code is to be read at various speeds.

I have automated my model rail layout and have learned (ie had many problems) much along the way!

I use the JMRI software (see google) which provides a framework that lets you do just about anything you like with model rail. The operative word is framework.... this is not a shrink-wrapped solution that you just install and it runs. Rather it provides a set of tools you can build together to achieve what you want.

The approach I took was to use IR leds/detectors across the track. I used a script that someone else had written that understands the track topology and allows you to enter schedules that a train should follow. The trains stop for signals or if the track ahead is not clear and all sorts of others stuff. The script is by Giorgio Tardini and is called AutoDespatcher2.

JMRI understands "block occupancy"and so I needed to write a script (jython) that used the knowledge of the trains initial location and sensor detections to translate to a block of track that was occupied.

I can happily run 3 trains on a 2.7x1.2 m layout that start/stop/speed up/slow down according to the positrons of other trains, point/turnout positions, the schedule that I have entered and so on.

The IR detectors are very simple IR led/detectors that cost a few cents each and draw around 20mA for a detection range of up to 10cm. I pulse them at 100Hz - not sure that this is very beneficial to be honest - but is about the fastest I can manage as I use a 23017 IO expander and I2C.

The uC communicates with my PC via RS232.... btw JMRI is available on MAC and Linux as well.

On of the biggest challenges was trying to copy with the gaps between carriages/loco in the train. I implemented hysteresis in the uC so that presence (IR broken) was detected quickly (about 30mS) and absence was detected more slowly (~150mS). At high speed the inter-carriage gap was not detected. At low speeds it was. to get around this I needed to (on the PC) take the train speed and estimate how long the gap would be and implement another layer of hysteresis on the PC!

An alternative would have been to increase the absence timeout significantly on the uC but this was not feasible for high speed operations. At low speed a train might move 1cm per second; At high speed it might be 10-20 cm/S.

So it definitely is feasible.

My approach was to keep the uC as simple as possible and put the complexity on the PC.

I have designed the sw on the uC to operate in increments of 8 detectors via I2C expanders. Using an ATMEG16 @ 8MHz the occupancy increases by 5-10% per group of 8 detectors...... ON my 2.7m x 1.2m layout I have found that I only need 6 detectors to fully automate the layout!

understanding where the location and ID is just the start of the challenge. you also need to understand the track topology including the dynamic aspects such as point position.

I have found it a lot of fun and a good learning experience in C++, Java, Jython, Train signalling......

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How many unique code do you need? The barcode could be really "rough" and basic. Eight bars, thick or thin, would still give you 256 codes. The "preamble" could be, say, 2 times a thick bar.

If the sampling is done with a well chosen frequency, then you do not need to synch the sampling frequency to perfection. Just let the preamble select a frequency that will make sure a buffer with samples will not be overrun. Then do the analysis after you've seen all the "bits in the package".

The main problem I see will be with trains doing acceleration or retardation during passage over the scanner. What happens if a train comes to a complete stop while the barcode is over the scanner?

One of my dream plans for retirement is to become a model train freak. I would like to go the other way around, having all the intelligence in the engine. In essence e.g. an on-board AVR acting as engineer/driver. You send to it what you want it to do ("drive to the next station") but while the driver is executing this it will also take into consideration signals and such along the track. In this scenario, the information goes the other way - from the track to the train ("the next signal is showing "drive 30").

There could still be central automation also, but this would i) just send the high level orders to the drivers, and ii) set signals, junctions etc.

You could even program a stochastic mistake into the drivers, and wait for the disaster.. :D

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Johan, if not already familiar then have a look at JMRI.... there are a lot of people there that are completely obsessed with trains and computers!

The intelligence in the loco is an interesting idea BUT you still need the off-board control for signals based on train location and point positions.

As usual it is the exceptional conditions, such as you have mentioned, that make the task challenging.

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Found the link on the RFID seminar: https://www.avrfreaks.net/index.p...

RFID tags http://www.ebay.com/bhp/rfid-tag...

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tricia, and Ulyana. You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yikes. If the engineers cant keep track of where the real trains are when they are on rails, how can we ever hope to get any progress on car autopilot? I have brainstormed on how to get a section of interstate networked up to have the cars able to join a drafting convoy to save gas. The cars would be instrumented with sensors to detect distance from a solid wall on one side (left in the US) and distance to the cars in front and back, and the hi way would have a network to keep the convoys spaced out etc. Cars would join and disconnect at the rear, and once locked in to a train/convoy a group could cruise at hi speed. The part that I can't crack is how to react to a blown tire in the middle of a 10 car pack going 80 mph with 5 ft spacing.
This idea is one level below full autonomous control, which would let grandma and grandpa dial in the kids address for Thankgiving and just go along for the ride.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

perhaps a bit off topic but have a look at this....
http://www.nydailynews.com/news/world/driverless-car-hits-road-article-1.956341

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
The part that I can't crack is how to react to a blown tire in the middle of a 10 car pack going 80 mph with 5 ft spacing.

Ah, the advantage of Mag Lev, no physical contact, no moving parts.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
no moving parts

Was that actually intended for the "sleeping groin" (sub)thread?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl: That's exactly what I had in mind initially, something like ERTMS. But I left the idea because it would need tiny SMD technology, which I don't have the equipment for.

I think the decentralised option isn't that bad as second-best option. It also has the advantage that the logic can be programmed on a full blown PC which of course is far less complex.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Plons wrote:
How about the IR bar reader, the samenkopen.net link I posted ?

I've left the idea of bar codes for the moment.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gregd99 wrote:

I have found it a lot of fun and a good learning experience in C++, Java, Jython, Train signalling......

I am an experienced (a.o.) C/C++ programmer (25 years...), the development of the software won't be the problem, believe me ;-) It's only last year I started with microcontrollers, so that is where my learning path is.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


The RFID tags themselves need not be cheap for this project, it's the readers ;-) And they're not quite...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Barcode decoding should not be that hard if you take a look at specification of few of them. They usually have some sort of way to allow you reader to syncronize reading speed to speed witch barcode is moveing.

heres for example commonly used EAN barcode system http://en.wikipedia.org/wiki/Int...(EAN)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is a fundamental difference though between a bar code reader and a stationary bar code "pickup" looking at the bottom of a train.

A bar code can (and will) scan the code several times a second, allowing it to find out the size of the code (comparable to the speed of the train in the other scenario), whilst the code/object itself remains stationary. On the other hand, the train pickup will have a one and single only opportunity to get the whole thing right, imho it's prone to fail.