I like the idea of using NV memory to store the state... it does however have the trade-off that if something is moved while the power is down, the counts will be off. How does the system recover from that? Are you storing the axle/car counts in NV or merely an "occupied" state indication? Is there a reset procedure of some kind to get things back in sync if the counts get off?
There will be a separate input/switch/pushbutton that the system will use to clear the count if required. I realized the double edge issue with memory, and that the state would have to be cleared sometimes. The state saved is the current count for the block, so it returns exactly to where it was before power was removed. The EEPROM memory has a definite limit to how many times it can be written to successfully, and that's taken into account. The memory is treated as a list with an end point, and each time it's written to, the new data overwrites the end point, and adds a new end point. So, the end point continually moves through the memory as the state is stored sequentually. The only valid data is the data just before the end point. The guaranteed number of write cycles that the ATMEL chip specifies is 100,000, but various destructive tests to see how many writes can be done before loss of function usually show that 1-3 million writes are likely before failure. These numbers may not be viable, because long term data retention was not tested, just the ability to write and then read the data. In my calculations, I only use the guaranteed published number from the manufacturer. Using the SWAG method of how many times a particular memory location is written to in various circumstances, I've calculated that the memory won't reach the maximum number of write cycles for decades of 'normal' use. My calculations were based on guesses as to how many detector transitions happen in 'normal' operation of a MRR layout, usin an 'average' length train and also guessing how often a train will pass a detector. The memory is completely written to ONCE every 512 detector transitions/detections.....that's on a per-block basis. So, simple mathematics shows that 512 X 100,000 is the number of transitions that can be successfully saved, or 51 MILLION detections. So, taking wild guesses as to how many transitions occur in any period show that if there are 2,000 transitions per hour, that'd be 25,600 hours worth of operation. That'd be 1,066 continuous 24 hour days of operation, or 2.9 years of continuous operation......I'd like to see the layout that could do that! Each average piece of rolling stock will generate 2 transitions (one for each truck), and assuming an average of 20 cars/locos per train, each train would only generate 40 transitions past a detector for each pass. Even in a train show, I don't expect more than 2 passes per minute, or 4,800 transitions per hour. So, for 8 hours, that would be 38,400 transitions. That's 3.7 years of continuous operations at the train show. Using similar numbers, on a real world MRR, I'd expect about a train passing a particular detector about every 4 minutes on average, and the operating session might be 4 hours or less. So, using these numbers, about 2,400 transitions would occur in an operating session. 51 million divided by 2,400 results in over 21,000 equivalent operating sessions before the memory limit is reached. Even if all these guesses are off by a factor of 10, that's over 2,000 operating session.....if a club operates EVERY week (no working on the layout), that's over 400 years of operating. In the real world of MRR, the memory should never be an issue. I sure hope my math is correct.....tell me what you think.
I have 2 digital still cameras that also have some video capability, and both of them are completely inadequate to make a usable video. One won't focus close than about 18", and the other is somewhat better, but only creates 20 second videos......what a major PITA. So now I'm searching for a loaner video digital camera to make the video. I think making the video will be harder than the engineering in actually creating the project! Anyway, here are some still photos of the components so you can see that it's a real project: View attachment 171719 View attachment 171720 View attachment 171721 View attachment 171722 View attachment 171723 View attachment 171724 View attachment 171719 View attachment 171720 View attachment 171721 View attachment 171722
After 25 years of installing/maintaining photo-eyes that count things (products, wheels on conveyors, vehicles entering/leaving an area, even welds in steel sheet traveling at close to 60 mph) I'll share some of my experience on why a reset is probably a good idea. The two biggest reasons for inaccurate counts are vibration and sensitivity. Once the count is off it stays off until reset. Vibration shouldn't be a major concern on a model railroad layout, but one never knows when a bump will occur. Bump or vibrate hard enough and the sensing components can be jarred out of alignment enough to miss some wheels and count others or not see any wheels at all after the vibration. Losing count is frustrating. Sensitivity can create havoc, too. Too sensitive and silly things like dark shadows or a wisp of paper can add counts, and not sensitive enough and some wheels might not get counted. Or a loco access ladder that hangs low can be counted as a wheel set, too. Concerning camera loans: sometimes local organizations have such items to loan or rent at reasonable rates. Sometimes you might even be able to get a grant to buy one if the reason is withing the interest range of the organization: Public libraries Veteran's Organizations Local government offices Civic organizations (Eagles, Rotary, etc.) These kinds of groups are a good source for small grants. Model railroad or similar clubs There are also a number of decent quality digital HD video cameras on the market for under $100.00 - and I don't mean $99.99. Check Amazon.com and websites for big box retailers; heck, even Walmart has a couple brand/models. It's something you might want to keep around for a variety of reason on and off the layout.
This system is based on a state machine, and the logic is amazingly reliable. Aligning the emitter and sensors is trivial, and far from critical. AAMOF, the alignment is NOT critical at all because the system is based on dual sensors, and the logic only cares it the sensor(s) are covered or not, AND the sequence of these events. The design is more-or-less based on the quadrature model of detection, and will NOT detect anything smaller than the distance between the 2 sensor 'lenses', and they're about 1/4" apart. So, there is no chance that small/trivial things can affect the count. If the profiles of the rolling stock was consistent, the sensors could easily count the cars themselves, but the only part that's consistant height above the rails are the couplers, and there isn't a gap between cars, so that wouldn't work. Wheels/wheelsets/trucks MUST be at a particular height (on the rails) so using the center of the wheel as a target for counting works exceedingly well. While I completely agree that forcing a block to a clear state is absolutely required, the likely use will be if rolling stock is manually removed from a block or switching work is done into/from a siding/block that's not covered by the system logic. My local MRR club is small, so no video equipment was available from that source. I'm retired and living on a fixed income, so expenditures beyond what I need to outlay beyond the actual engineering is not feasable. I will try other sources.....TIA (Thanks In Advance).
My video production ability really sucks, plus I don't have much patience, so I've got some video done, but it's just multiple segments, not one video. Hopefully you can actually hear my voice, and understand what I'm trying to explain...you'll get to see my mistakes. https://youtu.be/PiuKYxRF5Ns https://youtu.be/OM3Ytk7f1pw https://youtu.be/djAo_Nb4LB8 https://youtu.be/67U60EHDfr8
I just uploaded another video after I got the occupied indicator working, along with the memory implementation. I had to add some temporary contacts to the counter boards, because they don't have any copper connections for the required pins. You can see them in the video. Please commemt.....
GITHUB is not going to work for this....it's just too difficult to just upload some files. I need to upload the KICAD schematic and PCB files, plus 3 .ino files. Besides the code for the detector module and the counter module, a simple utility to run once to initialize the EEPROM will also be included. I will zip them up into 2 files, hopefully later today.
I see that this thread has generated a decent amout of traffic, but I've gotten absolutely no feedback......I see that some of the files were downloaded, but can't tell how many downloads have happened. Nobody has any questions??? If you like it, let me know....if you don't like it, let me know what the issues are, and maybe they can be addressed. If you don't understand how it works, just ask.....I apologize for the poor quality of the videos, but they get better to a degree. If you want something explained, just ask. TIA.
I've been working on 2 variations of my design.....one that supports 2 turnouts per block and one that includes a detector and counter on one Arduino. The 2 turnouts looks like it won't work without a complte redesign of the logic, and that won't be pursued. BUT, the combination of detector and counter looks like it will work just fine. BUT (I hate that word) it requires 7 of the analog inputs to be used as digital pins, which in itself isn't a problem.....the real problem is the placement of the holes for those pins on the different 'versions' of the Arduino PRO Mini boards from China. I've been choosing which boards to buy based on price AND what the pictures in the EBAY ad looks like, choosing the ones with the extra analog pins along the narrow top row (opposite the programming headder), but today when I got my latest shipment, the boards were not the same as the photos....I expect to get some type of refund, but that doesn't solve the problem. So, since the Arduino Nano brings out all the signals to well defined points on the PCB, I've decided to switch to it from the PRO parts. The costs are pretty close, and with careful shopping a Nano can be gotten for only about $0.50 more than a Pro mini. The savings using a single PCB (the PCB was the next most expensive part needed in the project, usually at least $1.50 each) more than makes up for the extra small cost increase, and you don't need a separate programmer. Obviously, the current designs will work with the PRO, so that investment won't be lost, but all my future work will be using the Nano as a starting point. BTW, my next project will be a MSS compatabile signaling/complex cascade board, also public domain. It's takes a backseat to my current projects, but it will be eventually available.
I use a $10 analog mini camera (with IR pass filter) and an IR LED on the target locomotive in my machine vision system. It is accurate to within an inch or so. Check it out at www.internetmodelrailroad.com. The automatic trip function uses it to make a trip with a stop on the siding and so forth. This one only does one locomotive and would require turning the LED on/off on the selected locomotive to pick the one to track. Works great and requires no layout wiring.
Interesting, but not really applicable to train detection for use in an environment running trains prototypically. Plus it would require every car to have an IR source, and having cameras mounted so people wouldn't get in the way appears problematic at best. Implementing it on a complex layout with multiple trains probably would be a nightmare for most people. Nice exercise is vision recognition, be I don't think it's really practical.....
I really like the idea of using two detectors to indicate travel direction. I just got in some IR components myself, maybe at some point I'll get free time to play with your ideas. Have you considered having an automatic counter reset after a certain number of seconds without a signal, or just allow for a discrepancy of X number of wheels? Say you get a count of 10 wheels entering a block, but on the other end you get a count of 8 or 12. If you allowed for, say, 2 seconds from the last count before deciding the train has passed, you could automatically correct for variations as discussed above. And perhaps you don't really need to know the exact wheel count, rather just a flag to indicate if the block is occupied or not. Using a flag instead of a counter would make it easier to deal with situations such as if the train stops directly over a sensor, where you might have some IR light still bleeding around the edge of a wheel and give a false counter increase as the level of light increases and decreases while the train is sitting still. Another method to increase reliability would be to align the sensors diagonally across the track over a short distance, so if the train does stop near the sensor, you would still know the blocks were occupied. Regarding your problems with the pinouts of the pro-mini boards... Have you considered using the pro-micro instead? I think that board is based off an open-source design, and I haven't seen any that vary in their pinouts. Plus that board has the USB port already built in. And one more comment regarding hiding the IR components... Has anyone considered keeping the components under the board and piping the light with fiber optic cable? OP noted that the emitter puts out a huge amount of light, so why not have a single emitter driving several locations by using the fiber to point the light where you need it? I would assume you could similarly use a fiber optic cable to receive the light and pipe it back to the receiver (although you may have to make adjustments to the sensitivity). You can paint everything but the end of the fiber to match your scenery, and this could be usable for ALL scales.
The system indeed keeps track of the exact count of things/axles in a block, but doesn't report that.....that information is suoperflous. It uses the count simply to determine occupancy. The logic is simple.....if the count is zero, the block is not occupied, otherwise it's occupied. I don't care if there is one thing or 10,000 things in the block.....the logic is the same. The block is occupied if the count is not zero, and yes, the logic can handle up to 32,768 things in a block, but I really don't expect that many on most layouts. If the block was cleared by a timer, how could you ever be sure that the occupancy is correct? Just take into account a very long train and/or a very short block, where the train wouldn't completely fit into a block. If that train stopped because the block in front was not clear, a timer would completely screw up the count, causing the occupsncy detection to be unreliable. Just accept the fact that the logic works well, and all you need to know is that a block is occupied or not.....how many things in the block is not relevent. That infication is the FLAG you're asking about, and is a logic 0 level signal. The logic/state machine completely takes into account the circumstance of a train stopped over a block, or even going back and forth repeatedly over a detector. It's RELIABLE, and all those circumstances are taken into account. The quadrature is based on digital logic, and doesn't care what the level of signal is.....think DIGITAL, not ANALOG. I can't build a ATMEL based system for less than I can buy and Arduino for. The only issue with the PRO Mini is the variance between board layout from different suppliers to match how they connect to my pcb to connect to the outside world. The Nano has ALL the pins defined (actually, it adds 2 extra analog pins compared to the UNO or PRO). The cost difference is inconsequential. The original engineering effort was exactly what you requested, but the cost to mate the fiber optic cable to the IR source was considerable, if consistency and reliability were important (and they ARE), plus the cable is very fragile, and breaks easily (internally, the cable still looks OK). Installing that on a layout would be very difficult, if not impossible, when multiples are required. The cables required that the rails be drilled to accept the cable end, and that isn't easy. As such, the original design would require a special short seqment if rail where the cable would be mounted, adding installation difficulty. The IR detection would also require 2 cables on the other rail opposite the IR source. Altogether, it wasn't practical to meet the design goals of functional and cheap. The IR can easily be hidden in scenery, and styrene is more or less transparent to IR, so you could mout them inside a structure. The design uses a 4.7K current limiting resistor to reduce the output if the IR source, but the specified value for use in a TV remote is 180. So, the values can be setup to increase the output if the structure you want to install it in is less transparent to IR. The system logic doesn't care how the IR is transmitted, so be my guest, and do what you wish.
I am investigating RFID right now from the point of view of knowing what is where, for my surround sound implementation. Using the 13.56 MHz band, detectors are CDN $30, the RFID tags are $2 or less. The detectors use I2C, so I can have them up to a couple of metres from either a Raspberry Pi or an Arduino. They would fit under the track. The RFID tags would stick to the underside of rolling stock (in my case locos). They have a range of up to 28 mm, so I don't see a problem with tags being too close together. My tests will determine whether this range is too optimistic. I am ordering a and some tags detector on Thursday so I can experiment over the weekend. I am blogging my design thoughts and progress over here.
Since you mentioned 13.56MHz, have you looked at the NFC technology? My understanding is that they are based on RFID, but you can actually store information in each tag (I've seen memory sized between 256bytes up to 1k) such as road name, car number, and date of purchase. I haven't found any tags smaller than 25mm (1 inch), which should be fine for scales down to HO and possibly N. There are a variety of options available on ebay. The common sensor sold there costs less than $4US, uses an SPI port, and is 40x60mm and fairly flat so it could also be built in right underneath the tracks. I have these on my list of "things to try" at some point, with the idea being to have some sensors at key locations on my layout so that I can confirm the train is pulling the cars it 'thinks' it is pulling and flag an additional warning to other locos if there are cars missing somewhere on the layout.
RFID is a subset of NFC. One uses an NFC controller to read an RFID tag. The tags have eeprom memory in various sizes as you indicate. The controller I am ordering is an NFC controller. There are tags that are smaller (I have found a promising 3 x 4 x 7 mm), which should be good down to z-scale. Testing will determine if range, sensitivity etc. are workable. I have created a thread entitled "NFC/RFID Block Detection" to carry this discussion forward.
Ah I didn't know that, good info. I did run across some that are 12x19mm and 144 bytes of memory for a decent price, which will fit nicely in my project. The biggest problem I'm going to have is a large number of my cars have a metal base, so I'll have to see how badly it blocks the signal or if I can read the tag while mounted on the side of the cars.
The metal base will an impact, certainly. I plan to stick my tags to the underside of my cars, even though they are plastic. I don't think they will be noticeable from anywhere actual people can stand and watch.
