Maintenance

[Geoff]

The Underground was running fine at the close of season. It would be fine to remove the controls any time and when you make the tweaks could you remove the automatic warmup side as since we have changed the power units away from the plastic units it no longer seems necessary to have them and to save ware and tear.
I don't know if the output to the track is set to full voltage, if it is not could that be increased and then I have a suitable variable resistor I could fit in the output to fine tune the speed of the train?

Geoff

[TerryJC]

Geoff,

Not a problem removing the warm up cycle. I presume that also means that we don't need the run every ten minutes if the train hasn't been used?

The PWM is set to 85% so I could turn it up to maximum if you want.

[Geoff]

Terry,

That's correct it doesn't need to run every 10 minutes.

It would be great to set the PWM to maximum. Then the variable resistor could sort the speed out.

Geoff

[Penri]

Hello

This morning I removed the underground control Raspberry Pi so Terry can do whatever needs to be done to it.

He and I also discussed, while he has it in his hands, adding network functionality to it, so that it can be accessed remotely to make changes to the software and potentially other things.

I talked with Peter quite a while ago about implementing network functionality in the railway room but never got around to doing anything about it, now seems like a good time to do so. With that is mind Terry will purchase the necessary networking bits then I'll install and test them in due course.


Penri

[TerryJC]

He and I also discussed, while he has it in his hands, adding network functionality to it, so that it can be accessed remotely to make changes to the software and potentially other things.

This morning I fired up the Underground Pi with a network connection and found that updates to the version installed don't appear to be supported any longer. Not only that, the file system is marked as Read-only, so I would be unable to write the updates to the SD Card anyway.

I'm not particularly surprised to find that the OS is no longer updated because when the system was installed in April 2019, the current version was Raspbian 'Stretch', which had been released almost two years earlier in August 2017. In fact the next version ('Buster') was released only a few months later in August of 2019.

A developer from the Raspberry Pi Foundation has stated on their Forums that support for OS updates was limited because the fragile nature of the SD Cards used to hold the software meant that extremely long lifetimes for any particular installation would be 'problematic' anyway.

This is not all doom and gloom for a couple of reasons. First; we could rebuild the SD Card from scratch using the latest version 'Bullseye'. This wouldn't take long, but we still wouldn't be able to update the OS, so we'd be in the same situation going forward.

The second reason is that if we do absolutely nothing as far updates are concerned and rely on the Read-only file system to protect the code on the Pi there shouldn't be much risk. The fact that the OS is marked as Read-only means that an attacker wouldn't be able to corrupt the files on the card anyway, so the Pi isn't anywhere near as vulnerable as might be thought. (There is a potential attack vector whereby an attacker manages to exploit a vulnerability on the Pi and use that to access the other Pis on the network, but if they'd got through the WMT Network security they are already in a position to attack the other Pis anyway.) Also the Read-only file system on the SD Card means that it is much less likely to be damaged by the day-to-day running of the system and there is nothing particularly useful in later versions of the Raspberry PI OS to make it worth installing from the standpoint of functionality. This is the 'if it ain't broke, don't fix it' philosophy. When we originally started putting Pis into the Railway Room, there was no thought of networking them and so there was a conscious decision not to update them for the reasons stated above.

I am proposing that we follow the second option. I would be interested to hear any viewpoints on this.

[TerryJC]

This morning I removed the underground control Raspberry Pi so Terry can do whatever needs to be done to it.

I thought it worth listing here the plans for the system over the coming weeks:

Hardware

• Add a WiFi Adaptor (removed from the Minster System) so that the Pi can connect to the WMT Network. This will allow me to modify the code remotely (see below).
• Add a WiFi Extender/Access Point in the Railway Room Store to provide access to the WMT from inside the Railway Room. This will also allow Visitors to continue to see the network when viewing the layout.
• Add some pull-up resistors to the Sensor inputs to the system prevent false triggering from noise in the wiring.
• Complete the development of the Over-current Protection Board so we won't have to rely on a fuse to prevent damage to the Motor Drive Boards.

Software

• Update the OS or not as the case may be (see my last post).
• Modify the program to remove the warm-up cycle as requested by Geoff above. Also increase the max PWM to 100%.
• Devise a method of allowing modification to the program remotely via the network, even though the file system is Read-Only. (This will require some thought and may involve a writable partition of the SD Card to contain the software).

I hope to have this completed within a few weeks, because I also have work to do on the Minster and River Systems.

[Penri]

Hello

The principal reason, but not necessarily the only reason, for WiFi in the Railway Room is to allow access to the Pi remotely for support and maintenance purposes. Experience over the past couple of years with the other connected Pis have demonstrated the benefits of having them so, in my view.

While I don't disagree with the arguments and preferred course of action in the previous post

"if it ain't broke, don't fix it philosophy"

the ability for someone with expertise to access the Pis remotely, if only to say they are working fine, would be most beneficial.

Although I'm still mystified by the underground issue and the subsequent "fix", having to take the Pi out to confirm the software was ok was a bit of a chore.


Penri

[TerryJC]

Penri,

Updating the OS and checking/modifying the program are really different issues. The 'if it ain't broke, don't fix it philosophy' was really to do with the former and I agree that remote access to the running code is needed even if we can't update the OS.

So my preferred solution is to make no attempts to update the OS but to move the program to a small writable partition. I may well add some logging too, to aid diagnosis, since we'll be able to read the logs remotely

[Penri]

Terry

I'm not as familiar with the S/W architecture as perhaps I should be, so I just wanted to state the case from an "users" perspective.

The solution you propose sounds fine to me.

Penri

[TerryJC]

Good. That's what I'll do and will be able to test it fairly soon.