Reintegration of the System with O/C Protection and WiFi

[TerryJC]

After the issues towards the end of last season, it was determined that the original Over-current Protection Circuit wasn't working reliably. Penri removed the system at the beginning of the Winter Maintenance Period and I've had it ever since developing an alternative approach. This proved more problematic than expected and the work got interrupted with other activities (Minster Music, Lady Hanham River System modules etc), so the work on the protection circuit has only just been completed.

So over the coming days I hope to:

• Rewire the Over-current Protection Circuit into the system.
• Set up WiFi networking.
• Partition the SD Card so that the OS can continue running on a Read-only file system while the Underground Railway software is writable.
• Return the fully integrated system to Penri for re-installation.

The presence of the Read-only file system on the existing SD Card will necessitate me setting up the system from scratch. This will allow me to configure the networking properly and re-locate the program. I will take the opportunity to install the latest Raspberry PI OS.

I will report progress here.

[TerryJC]

I found that the wiring Diagram for the system was out of date and have brought it into line with reality again. This will find it's way into the formal docs in due course.

[TerryJC]

Sitrep:

The problem with the false sensor triggers that appeared to develop during the last season have proved to be more complicated than I thought. Initially I thought that the inputs needed pulling down, but then discovered an error in the software (the inputs were pulled up in software, instead of down). However, neither of these possibilities have proved to be the problem. (Apart from anything else, this software worked once.)

I think pull-downs may be needed, because the inputs sit at between 0.5 an 0.9 V without them. However, the software still fails to see the low inputs and triggers immediately. If I measure at the output of the input buffer, I get 0 V or 3.3 V when the I/P is floating and 0 V when it is pulled down. The Pi still fails to see the low however, so there is something else amiss.

My first thought is that the 0 V connection to the Pi is bad, but I've been unable to find any problems so far. I'll have to run a standalone program to see what works, which will mean that I'll need a writable SD Card; this one is Read-only. I'll think about the best way to diagnose this problem overnight.

Penri,

Any other ideas?

[Penri]

Terry

In para. 1 above are you taking about the i/p of the Pi or of the buffer (74HC4050)?

Reading the spec sheet for the buffer (which annoyingly does not spec performance at 3.3V) and interpolating performance at 3.3V, for the device to work properly a low i/p need to be less than ~0.9V and a high i/p more than ~2.5V. Although the measured i/p of 0.5 to 0.9V meets the criteria for a low I would be happier if it was a lot more solid and perhaps less than 0.2V.

I can't help with why the Pi S/W can't register a 0V i/p but its worth checking that the buffer, sensors and Pi all share a common ground.

I have seen cases in the distant past when two (single ended) logic devices, which didn't shares a common ground (because of a wiring issue), sometime work and sometimes didn't, the disconnected device floated up of down dependant on whether the logic signal was Hi or Lo.

Do you have any data on the IR sensors, labels A, B, C and D on the circuit block diagram?

Penri

[TerryJC]

After sleeping on this, I think I agree with your analysis.

In para. 1 above are you taking about the i/p of the Pi or of the buffer (74HC4050)?

Both actually. At the input to the buffer, I get the mentioned 0.5 - 0.9 V, unless I pull it down. At the input to the Pi, the software allows for a pull-down, but that doesn't help if the output of the buffer is erroneously high.

Reading the spec sheet for the buffer (which annoyingly does not spec performance at 3.3V) and interpolating performance at 3.3V, for the device to work properly a low i/p need to be less than ~0.9V and a high i/p more than ~2.5V. Although the measured i/p of 0.5 to 0.9V meets the criteria for a low I would be happier if it was a lot more solid and perhaps less than 0.2V.

I don't think that this is the problem, (because it all worked once), but I'm going to see if I can attached a resistor pack to the underside of the Veroboard to make sure.

I can't help with why the Pi S/W can't register a 0V i/p but its worth checking that the buffer, sensors and Pi all share a common ground.

I have seen cases in the distant past when two (single ended) logic devices, which didn't shares a common ground (because of a wiring issue), sometime work and sometimes didn't, the disconnected device floated up of down dependant on whether the logic signal was Hi or Lo.

That's my next step. The Pi does appear to be at ground; as measured by an Ohmmeter, but that would be true even if the connection between Pin 9 on the Pi and Pin B on the Veroboard was poor. The path to ground through the power supply would not be good enough, I'm thinking.

Do you have any data on the IR sensors, labels A, B, C and D on the circuit block diagram?

As I recall, we only had a paper copy of these (it may be in the spares box). In any case, this isn't a factor, because the problem occurs with the test circuit.

[TerryJC]

Here is what I've found:

• The Pi is working fine when I run the program with the interfacing disconnected and using a resistor to 3.3 V to create the high.
• When the interfacing is run standalone, the outputs of the buffer are high or low depending on which channel; Channels 1, 3 and 4 are high more often than not, but Channel 2 seems to work,
• If I pull the inputs down the buffers work as advertised.
• When I connect my test circuit to the inputs on TB1b, the outputs immediately go high.

Here is the Interfacing for this bit:

Sensor_IF.png (100.8 KiB) Viewed 243 times

and here is the relevant part of the test circuit:

Underground_Railway_Test_Circuit.png (47.96 KiB) Viewed 243 times

I'm not sure why connecting the test circuit causes the effect it does, presumably noise.

I'm currently trying to see how to shoe horn four pull-downs onto the main Veroboard. However, this all worked once, so:

Do you have any data on the IR sensors, labels A, B, C and D on the circuit block diagram?

As I recall, we only had a paper copy of these (it may be in the spares box). In any case, this isn't a factor, because the problem occurs with the test circuit.

In fact it looks as if I need that info to be sure that it will all work, when it's connected. I've spoken to Clive to see if he has a copy of it.

[Penri]

Terry

There may be leakage path through the switches or prototyping board, it wouldn’t take much current to stimulate the buffer I/p. Once the buffer is high then there’s no path to ground to remove the charge on the I/p.
A TTL version would probably work ok because of the higher leakage currents in bipolar transistors but CMOS devices don’t have those same characteristics.
Penri

[TerryJC]

There may be leakage path through the switches or prototyping board, it wouldn’t take much current to stimulate the buffer I/p. Once the buffer is high then there’s no path to ground to remove the charge on the I/p.
A TTL version would probably work ok because of the higher leakage currents in bipolar transistors but CMOS devices don’t have those same characteristics.

I've been wondering about that. I now have the four inputs pulled down and the buffers switch nicely when the buttons are pressed. This was far from easy because there's no convenient copper conductors left, so I had to piggy back a resistor pack onto the board and run wires to the pins.

I've also had a response from Clive. He didn't have much info to help in his own records, but he did have a link to the supplier's site. The only info there is how to wire the sensor; it gives no indication of whether the switch is a relay, a driver device or open-collector. I suspect the latter so apart from the driver case, the inputs are likely to float without pull-downs.

I now have to re-assemble the interface which will take me a while. If that works, then I'm hopeful that this will work in site.

[Penri]

Terry

Do you know if the sensor is an IRDOT-1 from Heathcote, http://www.heathcote-electronics.co.uk/irdot1.html, one of my neighbours used some on his loft railway layout? If so the quoted connection info. for the device is:

Terminal 1 Connects to the positive terminal of the power supply
Terminal 2 Electronic switch (open collector transistor) for connection to our other units such as SA8.
Terminal 3 11 volts output used for relays and undetected LEDs
Terminal 4 Not used
Terminal 5 Connects to the long leg of the LED
Terminal 6 Connects to the negative power supply and short leg of the LED

I couldn't find a circuit diagram for the device on-line but did see a max. pull down rating for Terminal 2 of 100mA. Terminal 5s current sourcing capability is not specified, or rather I couldn't find anything stated.

Penri

[TerryJC]

Penri,

That's the link that Clive gave me. I can't remember which IRDOT we have and the lack of specification about the nature of the O/P on Terminal 5 didn't help. I can't remember which terminal the guys used (Terminal 2 or 5), I assume 5, because 2 is intended to show a green LED when the device is not triggered. I suspect either will float if not terminated.

As long as the kit works on the test circuit, I expect that it should work on the track.