There isn't a whole lot of space on the circuit board, and orientation of a couple parts is not obvious from the board, so it's important to follow the instructions carefully. I hot-glued the LocoNet sockets into the box and added more screws for additional stability.
I also used the opportunity to build LocoNet boxes by HOfine. These are commonly used at FREMO modular meets for plugin throttles. I put the cable tester to good use on the boxes.
My workbench has been an unmitigated disaster for many months now.
Half-finished, started, abandoned, and stalled projects were piling up and collecting dust in a corner of our dining room. I'm truly thankful that my wife hasn't put me in the dog house yet. With the Silicon Valley Lines events wrapped up for the year and a holiday week coming up, this weekend was a good opportunity to clean ship. I threw out what I no longer needed, sorted and packed away what I don't need right now, and organized projects for the near future.
The following might make an appearance on this blog soon:
Remotely controlled train 4837 entering Kaos Jct on a green signal
The Silicon Valley Lines Fall Open House is in the box. I had a lot of fun, but as such events go, it was also stressful. The video-enabled Webthrottle worked well for remote visitors, once we got over a major mistake I made when sending the throttle URLs to the first visitor group.
After that I got more into a rhythm: Send emails with personalized throttle links to confirmed visitors, have them join on the video conference, give introduction talk, hand off to train master, and while the session is running work on the next batch of emails.
At the Audio/Video control stand preparing email notifications for the next session (Photo Credit : Josh)
We had planned for running a round-trip session every 20 minutes. That was a bit too aggressive, since it takes a train about 15 minutes to drive the Open House loop. We had pre-staged trains around the layout, so 3 visitors could start with running their train right away. However, 5 minutes was not enough to get operators on the video conference, familiarize them with the throttle control, and oriented on the layout. Including an occasional break for the crew would have been nice, too. When we do this again, we should clock the departures on half hour increments, but otherwise can use the same process.
I lost all audio output on the main computer controlling the Youtube Live stream for a while, and couldn't get the audio working again, so I substituted with a room microphone. However, audio quality on that microphone was very poor. Now -- with some distance -- I'm thinking I should have restarted the computer at the cost of dropping the live stream for a while. That would have been better than having the live stream with no usable audio.
Train 161 rounding the curve at Bayshore
The crew in the layout room was great. The cameras and the trains worked really well. The DSL connection held up well with only minimal drops affecting quality, even though we had the upstream bandwidth maxed out at times.
We learned a lot during this Open House, which was probably the first time ever multiple remote operators ran trains on a club layout in parallel with individual video feedback. We have a long list of things we can improve on, but we'll get to that another time.
As we shut down the layout in the afternoon and closed up shop, everyone was tired, but happy. I got only positive feedback from visitors during and after their sessions. This was a long day, but totally worth it.
Back in September, as we were gearing up for another full-blown socially-distanced ops session at Silicon Valley Lines, I quickly needed to build another camera car. I had already built a supplementary power supply for James' Dash9 dummy locomotive using a well car and a 10,000 mAh USB power bank. I wanted a self-contained camera car, so I decided to build a cradle for the second power bank I had, and mount the camera on the side of the power bank. That setup became Cam3.
This worked, and we used the car in ops sessions since. However, over time it became obvious that for some reason this car had worse wifi reception than Cam4, my original camera design. That's very curious since it's basically the same hardware ... with two exceptions: Cam4 is powered with a JuiceBoxZero connected to a Li-Ion battery, and Cam3 hugs a big hunk of metal. Side by side comparisons showed that Cam3 performed clearly worse than Cam4, even after reducing the network data requirements of the video streams as can be seen in the SVL operator training video.
After acquiring a power bank in a smaller form factor, as well as a low-profile, right-angle Micro-USB plug I was ready to replace the first design for mounting Cam3. I decided to install the PiZero horizontally, but since the USB plug is sticking out quite a bit, I mounted the PiZero on a styrene sheet and built a support structure into the well car with the PiZero mount sticking out about 1/4" on both sides of the car. I verified with an NMRA gauge that the wider platform is still within the loading gauge. Next I built a camera mount over the board and was very satisfied with my work. Here is Cam3 on the well car next to Cam4 ...
That satisfaction lasted for about 5 minutes, when I remembered that we have a couple signal masts in Jacksonville that are mounted between the tracks and clearly this arrangement is not going to fit.
It was time for design number three, which I call "The Fin".
I rotated the camera 90 degrees, so that it stands on its side. The angled Micro USB plug is now at the top and the USB cable threaded through the support structure.
I was careful to make sure that the camera is well behind the lead truck. I needed to rotate the camera image, which is easily accomplished by passing -rot 90 to mjpg_streamer. I'd still like to find an actual low-profile Micro-USB plug. There are some variants of what I'm thinking of available from Chinese suppliers (e.g. reasonably cheap on aliexpress.com, or very expensive on amazon.com), but they all have lead times of about 4 weeks and the plugs look very finicky and prone to failure. It's probably easier, and definitely cheaper, to just solder the charging leads directly to the PiZero.
In either case, now that I liberated Cam3 from the hunk of metal, it seems to performs much more smoothly.
Last Friday I went to the club layout and tested the Web Throttle code. The code worked, but video quality was terrible. As soon as I tried to get two video feeds off the camera to WebThrottle and OBS respectively, the video streams produced only one image every 10 seconds at best. That's clearly not acceptable for what we are trying to do here.
I experimented with camera settings over the weekend at home. My theory was that due to the difficult Wifi conditions in the layout room, we're simply not getting the network throughput we need to get stable video streams. When running two streams at home I found that the PiZero kept a network send queue of more than two Megabyte or more, i.e. mjpg_streamer is stuffing bytes into the network queue, but they are not making it off the device fast enough. Eventually, buffers will overflow, the network code backs off, the queue drains out, and we see skipped video. In tunnel sections on the Welztalbahn, the queue dropped to about one Megabyte. My tunnels are very dark, so the jpgs produced by mjpg_streamer are much smaller and the network can catch up. In addition, the PiZero CPU was only about 30% idle when processing camera data to two streams when a train is moving. Not a lot of headroom. As a consequence, while the video works ok, even at home it was a bit choppy.
So with two streams we are simply pushing too much data into the network layer that can't get drained out fast enough over the network. The solution is to push less data. I reduced the video resolution from 640x480@15fps to 480x360@10fps, which reduces the raw bandwidth need to about one third. Testing on the Welztalbahn yielded a very smooth and stable video stream.
Sunday evening I was back at SVL and tested my theory at the layout. A single WebThrottle stream to my smartphone was smooth and stable, even in the Cavenaugh area that is particularly problematic. Next I pulled out the laptop with OBS and streamed the camera feed to Youtube while working on mounting location signs for the upcoming Open House. While before we often had a lag of a bit less than 5 seconds when watching the camera stream, video now was almost realtime and so smooth that you can see the flat car sway back and forth on the rails.
Towards the end of the evening, I pulled out camera 3 which is known to have reception issues because of how the PiZero sits right next to the large USB power bank. With the adjusted settings, quality is better, but still visibly worse than camera 4. You can see the difference side by side starting around 1:08:00 in the work video. That needs to be get fixed before Saturday.
I used the work video source to make an instructional video for Open House operators showing how to use the WebThrottle and what the location signs look like.
Today was last week's hike in reverse. We drove to the top of Mt. Umunhum, car-pooled to the Bald Mountain parking lot and hiked back up to the top. A nice hike, not too tough, and good views, despite the low clouds.
The cube is fascinating, even on the second visit.
In preparation for the upcoming Virtual Open House at Silicon Valley Lines, I have been toying with the JMRI Web Throttle code to integrate a video view. I also somewhat limited Web Throttle functionality to meet the needs of the Open House setup. It's not perfect, but seems to work reasonably well on the Welztalbahn. The real test will be Friday evening, when I'll try this out at the club.
Contrary to the earlier tests I did, this version's video link URL and locomotive name are set dynamically in JMRI, so that it works correctly even for remote operators out on the Internet.
Silicon Valley Lines ran another operations session with remote operators and a socially distanced skeleton crew in the layout room. This time around the technology worked smoothly. The upgraded Internet connection performed well and we had sufficient bandwidth to run video conference sessions and Youtube Live stream in parallel. The screenshot above shows the cab view perspectives from passenger train 18 in Igo controlled by a club member in the UK as its getting passed by passenger train 111. High priority train 104 is holding in Jacksonville for train 18 to get moving again. Meanwhile train 102 is ready to depart in Windsor pending assignment of a remote operator.
Two local operators took care of switching assignments. An on-site brakeman worked with remote operators to assist with easy switching chores, or if there were derailments. The Nowheres Yardmaster set up or broke down trains. I worked the A/V job and helped out with brakeman duties as necessary. I spent most of the evening in front of computer screens.
I went back to the control stand setup I used in June, since that proofed to be the approach with the least problems. The 17" MacBook Pro in the middle is running OBS, acts as the hub for all the cameras, and feeds the layout views to the participants on Google Meet via the OBS Virtual Camera, streams to Youtube Live, and keeps a local recording of the session. This laptop also bridges the audio from Meet into the Youtube stream and the recording.
The old Dell Inspiron on the right is also logged in to Google Meet and acts as the bridge for the FRS radios. After lots of trial and error I determined that the TRRS audio socket on the MacBook Pro does not activate the microphone input when I plug in the radio, probably due to the radio output not matching expected impedance. The Dell has separate microphone and speaker sockets and doesn't try to do anything fancy. This setup also allowed me to wear an ear bud for radio communication, while at the same time listen on the video conference with another ear bud and debug problems bridging the audio on the fly.
Finally, the 15" MacBook Pro on the left is set to the Youtube Live Control Room. I can observe stream quality, concurrent viewers, etc. as well as watch and add comments on the live stream.
The recording of the live stream is linked below. Watch it on the Youtube site to get a playback of the live comments, too.
The technology worked. What can we do better next time? Watching the stream it's pretty obvious that we need to be a bit more formal in our communications protocol to allow for effective radio traffic.
The lag between the FRS radio VOX feature to enable / disable the radio transmitter is causing confusion.
For the next session and the Open House in November we will need to think some more about how having a host for the event.
Overall, this was a fun session. We had many participants both on the live stream and the video conference, and I'm particularly pleased that with the upgraded Internet capacity a lot of the the technical problems we had in earlier sessions got addressed.
Today's hike takes us to Sierra Azul Open Space Preserve, better known as Mt. Unumhum, the mountain with that big cube on top, visible from all of the South Bay.
This used to be a military installation with a big radar antenna on top providing the U.S. between 1957 and 1980 with early warnings if invaders were to arrive from across the Pacific. Modern technology has rendered the radar station on the mountain useless and the military left in the early 1980's. The Mid-Peninsula Regional Open Space District acquired the land. After years of cleanup, the mountain opened for public use in 2017.
Because we had never hiked this trail before, didn't know how steep it was, and didn't want to make this a day hike, we decided to leave our cars at the Bald Mountain parking lot, car pool to the top of Mt. Unumhum, and hike from the top down to the parking lot. The trail has an elevation difference of 1150 ft and is 3.8 miles long.
The view from the top in the shadow of the cube is gorgeous, but obviously having a clear day would help.
The trail is mostly shaded for the upper 3 miles, many switch backs with an easy, but steady elevation gain.
On the lower elevations, there's less shade, but still nice views.
A very nice hike. Next time we'll do it in reverse and hike up to the top.
The San Lorenzo River bridge at Henry Cowell Redwoods is part of the original rail route from San Jose over the Santa Cruz Mountains to Santa Cruz opened in 1875. The current steel through truss bridge was built in 1909. Today the route is owned and operated by Roaring Camp.
Most of the usual crew got together today for a round on Fortini Trail in Santa Teresa County Park. Some of the switchbacks can be seen in the photo. below. It was a perfect day, nice and cool, yet sunny, with nice views. What else can you ask for?
When we got back to the parking lot we watched a group of fire engines from Milpitas, San Jose, Santa Clara, and Palo Alto. They were prepositioned in the park due to the bone-dry conditions and high winds warning this weekend, so that they can respond to any fire quickly. Since there was no active fire, they took the opportunity to train together, and practiced driving their engines in steep terrain.
These days cross-Atlantic trips are a rarity. We used the opportunity of my wife's family visit to bring along some of the items that had accumulated at my parent's house over the last 9 months. I now have plenty of stuff to read over the upcoming winter ..
A week ago I showed an actual prototype Zugschlusssignal ("end of train signal"). Here's the HO version attached to a short train leaving Emsingen.
The effect is very subtle, but significantly increases realism. Making these is an extremely fiddly task. I hope to get better at it with more practice. The etching is from digitalzentrale.de. The etched parts need to be folded and painted. To mount on a car, the part merely gets hung over the buffers and pushed towards the car body. That makes the mount pretty much disappears from view as it lines up with the black running gear of the car. Painting the red and white signal cleanly is difficult. Even though the signal has etched paint guides and I'm using a toothpick instead of a brush, my painting accuracy needs more work. There's plenty of opportunity to practice: I have 20 parts, with 2 signals each, front and back, so I'll need to paint 80 signals... I should have ordered the decal sheet.
I'm toying with integrating a video view into the JMRI Web Throttle. This is currently very much a proof of concept. After an evening of messing with JavaScript, which I haven't done in many years, it's working reasonably well. The throttle pane is the box on the left (or on the right, depending on personal preferences). The video window is in the middle under the function buttons. The function buttons are basically useless for a remote operator. You can't see the locomotive and you can't hear it either.
The idea is to use this interface for remote operations in situations where I want to limit which locomotives remote operators are able to control, e.g. in a Virtual Open House setup. This is to limit potential abuse by visitors from the Internet, where it is easy to hide. Since it is difficult to kick people off a public Web site without shutting it down for everyone, I'd like to avoid giving people full control of the layout through the Withrottle API. The Web Throttle is nice because it only gives access to locomotives that are included in the JMRI engine roster. By controlling what's in the roster, I can control which engines are shown to to remote operators.
The video stream currently comes directly from the camera. I need to find a way to proxy the video stream to the engineer to mimize lag, while providing an overview of what's going on for everybody else.
These days, due to COVID-19, I'm working from home. I'm trying to spend at least some time working from the backyard patio each day. This guy and his friend keep me company all day long.
For the last couple days I've been working on annotating the track plans for Silicon Valley Lines with industries, buildings, scenery features, etc. in preparation for publication. That was a lot of work, but I finally got it done tonight. Just in time for the deadline I was given. Phew.
The Zugschlusssignal ("end of train signal") must be mounted at the end of the last car of a train. It is made from metal and there are usually two such markers at the end of the train. Station agents and operators along the tracks observe passing trains and note the complete passing once they see the Zugschlusssignal.
This marker is commonly used on freight trains, while passenger cars usually have lighted red end of train markers.
Wouldn't it be interesting to include proper placement of such signal in the operations scheme of our model railroads?
After the arrival of Dg 6946 in Horb (active staging) the local switcher is sorting cars
Among many other things, over the last few weeks I worked out an operations plan for the Welztalbahn with the modular extension. Tonight I tested out the first part of that hampered by many technical issues. I need to operate the layout more often and more regularly.
