Solar System Check-In

Back in March I mused that summer production with the new inverter should produce a nice rounded curve with the sun higher up in the sky. And indeed it does.

After months of waiting, the Tesla Gateway has finally arrived. As much as I dislike the Tesla app, and Tesla's decision to make the app the only place where one can access the solar system's data, it is nice to check in on production from the comfort of the couch.

Solar System Refresh

Back in 2007, we installed our rooftop solar system. The SolarCity installer told us that we should plan on replacing the Xantrex Inverter after about 10-12 years. It lasted 13 years and finally died last fall. Tesla gave us a pretty good deal on a replacement inverter and in early February, our new Delta inverter went online.

I'm still waiting for the Tesla gateway to arrive so we can set up remote monitoring. Meanwhile, I'm checking in on the system from my phone using the inverter's Bluetooth connection. The app I use is called Delta M Professional. It is quite bare bones, but gets the job done. Our system is still producing 3 kW at peak, the panels are holding up well in year 14. In the afternoon we have some shading from one of the trees in the backyard, hence the uneven downswing of the power production curve. This will get better in the summer months when the sun is higher in the sky during the afternoon.

Yesterday was a pretty good day with clear skies and we produced over 18 kWh, which is roughly inline with March historic production.

SVL: Upgrade Orgy

I spent most of the day today at Silicon Valley Lines tending to deferred computer maintenance. I upgraded the computer running DecoderPro at the programming track, and the layout computer to Catalina which is the latest version of MacOS X that will run on these somewhat old machines. Downloading OS versions, installing them, and applying point updates took a loooong time. Once the OS was updated, I double-checked the JMRI installation. I needed updated drivers for the USB to serial converters built into the NCE USB interface and the LCCBuffer USB, but that was easily accomplished, once I figured out which exact drivers I needed. I upgraded JMRI to version 4.22 on both computers through a couple intermediate steps at 4.12, 4.18, and 4.20 as recommended in the release notes. The upgrade process itself -- while boring -- went off mostly without problems. 

JMRI changed behavior in the JSON interface with regards to notifications around version 4.15, which breaks the integration of the custom web panels we use for controlling the layout. We'll need to dig a bit deeper to understand how to fix that. This problem was the main reason the layout computer was still running JMRI 4.14 so we have known about this problem for a while. It's time for a fix.

While the computers were downloading and updating stuff, I filled out the submission paperwork for inspection of the cars I built, decaled, and weathered over the last year. I also measured wifi signal quality around the layout room to help with investigations to improve quality of our cab cams.

Overall, a productive day, even though it doesn't feel like it.

Update 2021/03/14:
We've traced the change in behavior to JMRI being more strict about JSON requests and requiring a method field in the JSON data our panels send to the server.

A keep-alive for Maerklin 37180 (094 232-6)

Maerklin's 37180 model of BR94 in early era IV livery is a beautiful model. In addition, it's lettered for BD Stuttgart, Bw Crailsheim which makes it perfect for use on the projected Murrbahn layout.

Even though I don't have any photographic evidence that a BR94 was operated between Backnang and Gaildorf/West in the early 1970's, the opportunity to pick up a model that could have been running at least nearby was too good to pass up.

Meanwhile, it's a great switching engine for sessions on the Welztalbahn. There's only one catch: The power pickup seems to be a bit finicky and there is minimal run-out distance on my model, despite the motor having an -- admittedly small -- flywheel.  Other modelers reported not having any problems, so maybe I'm particularly picky, or the pickup shoe needs some love. In any case, I want to use this engine in situations that require slow switching moves and nothing is more annoying than the locomotive getting stuck on a yard ladder turnout. Hence, I looked into what it would take to install a keep-alive, in addition to a mechanical review of the pickup shoe. 

This is a tender locomotive, which are not exactly blessed with space, so I searched for really small keep-alive units. Tams usv-mini have a nifty way to hardwire with any decoder, so that the keep-alive is turned off during programming, which I would have preferred for this application. However, the TCS KA2 is much easier to source in the U.S. Since the locomotive has a MTC21 connector, the KA2 can be hardwired to pins 16 and 20 of the plug. No modification of the decoder is needed.

Contrary to my 10 year old BR86, with this locomotive Maerklin managed to keep the view through the cab open. This allows me to install figures for engineer and brakeman, as well as hide the KA2 in the rear of the cab. With a size of only 9 x 9 x 15.5mm the unit is truly tiny.

I spent most of the evening carefully disassembling the cab, plotting where to install the KA2, and painting the unit black. That's good enough for tonight.

More LocoNet Components

One of my projects today: I'm finally building a LocoNet cable tester. This is a design created for FREMO. While putting the kit together, I watched more footage from yesterday's NMRAx event.

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.

SVL: Fixing CabCam video throughput issues

 

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.

SVL: JMRI WebThrottle with Cab View Video Feed

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.

ESU Lokprogrammer

A little while ago, I ordered a Piko BR221. Very nice model, but doesn't come with sound, so I also ordered a Loksound5 and asked the dealer to program it with the V200.1 sound package. Usually that works flawlessly, but not this time. I got an empty Loksound5 with only the default sounds, and a note that it was programmed. Urgh. No point to send this back to Germany.

To fix the programming I borrowed an ESU LokProgrammer from another ETE member. The unit had been rarely used and mostly sat on a shelf since 2011.

The LokProgrammer comes with a serial port. It took me a while to hash out problems with the USB/Serial cable that was in the box. ESU ships USB/Serial cables with a chipset from FTDI, but the cable I had came up as Prolific and the driver refused to function. I eventually determined that this was not an original ESU cable and tried using an USB/Serial cable with a FTDI chipset I had at hand. That worked and the LokProgrammer software was able to detect the LokProgrammer. The program's UI is functional, but not exactly user friendly or logical. It feels like 20+ year old software ... which it is.

Nevertheless, 30 minutes later the BR221 had the sounds programmed properly, and when firing it up I got the rumbling sounds of the two Maybach 12 cylinder diesels. 

SVL: Audio Cable for FRS radio

When I last played with connecting an FRS radio to the computer, I didn't connect the radio directly to the computer, because a) I didn't know what the pin-out of the radio was, b) I read that connecting line out to microphone input can blow the microphone circuit, and c) I didn't have enough time to test things out.

In the meantime I learned that connecting output to microphone input works if you are careful with volume levels. I also found out what the pinout of the headset plug in my Motorola Talkabout EM1000R is. Hence, tonight I sat down and butchered some cables. The wiring is very simple:

The Motorola EM1000R FRS radio has a 2.5mm plug with a shorter than normal shaft, i.e. only 2.5mm plugs specifically designed for this (and similar) radio fit. I solved that problem by cutting the plug off my crappy and uncomfortable Motorola headset purchased years ago. The photo below shows the cable in operation with separate microphone and stereo 3.5mm plugs. The wiring works similar to the 4 pole TRRS plug: Ground at the shaft, and signal (Mic or Left) at the tip of the respective 3.5mm plug.

SVL: Looking Around The Corner

[ CabCam posts ]

When mounting a camera on a flat car for layout videos or remote operators, a common approach is to set the camera close to the front of the flat car, since we want to give the illusion of being in a locomotive cab. Seeing the front of the flat car destroys that illusion.

However, doing this has an unfortunate side-effect: Depending on the length of the flat car used viewers now complain that they can't see as much of the scenery along the track as they had hoped. Especially in tighter curves there is a distinct lack of scenery visible on the inside of the curve.

The camera doesn't "look around the corner".

Part of the reason for this is basic geometry: The car rides on a curve. The center of the camera view is on a tangent off the center of the curved track. Hence, the center line of the camera image and the center line of the track diverge. The tighter the curve, the larger the divergence, the more scenery on the outside of the curve is taking up screen real estate on the inner side of the camera view.

An additional factor is the length of the flat car. The longer the car, the more the ends of the car hang to the outside of the track center line, making the natural tangent effect worse.

The effect is demonstrated by the car in the middle above. The teal triangle simulates the view of a camera mounted at the very front of the car looking straight ahead. Barely anything to the right of the track is is visible to the camera, while plenty of scenery to the left of the track can be admired.

There are multiple ways to even this out:

• Mount the camera in or near the front, but use a short flat car: By reducing the overhang at the end of the car, the camera's lens is positioned closer to the tangent off the track center line. Positioning the camera above the center of the front truck, or front axle, minimizes the overhang.
• Using a long flat car, mount the camera in the middle of the car: Long cars have an overhang to the outside of the curve at the car ends, and an overhang to the inside of the curve in the middle of the car. We can use the middle overhang to move the center line of the camera to the inside of the curved track center line and pick up more visibility.
• Using a long flat car, mount the camera in the rear of the car: Moving the camera further towards the rear of the car creates a "steering effect" where the front truck is "turning the car deck into the curve." In this setup the camera center line is not on a tangent off the curve, but on a chord. Hence the camera view captures much more of the scenery to the inside of the curve as demonstrated by the car on the right in the image above.
• Using a wide-angle or fish-eye camera lens can help as well, but results in distortions along the edges of the image.

Using a single long flat car is convenient, since it has plenty of space for the camera and supporting gear like batteries.

If too much of the front half of the car is visible in the resulting video, in many cases cropping the video can hide the car deck. If that's not possible or insufficient, push the camera lens forward until the car deck is no longer visible. This will still produce a better video experience than mounting the camera at the very front of the car. Alternatively, use two flat cars. The front car holds the camera pushed as far to the rear as possible, and the second flat car holds the support gear.

Magnifying Glass with LED light

My eye sight used to be better. I guess I'm getting older ... Working with small detail parts or soldering in tight quarters is a bit of a gamble. The Brightech LightView PRO is a 5 inch magnifying glass with built in LED light. The arm mounts to the work bench. 

I tested it with soldering the parts for the SWD Fredi. It takes a little bit practice to get used to the magnifying glass, but then it's a real joy to work with. 

My first SWD Fredi

Tonight I built my first SWD Fredi. The instructions are easy to follow, but only accessible to FREMO members. I have two kits. One was built tonight. I guess I'll do the other one tomorrow.

The main board comes partially assembled. All the SMD parts are installed, and I just need to do the regular sized parts like connectors, LEDs, and buttons.

LEDs are soldered to the board. Moving on to the buttons.

Finally, I work on the direction switch and the speed knob. 

A locomotive gets assigned to the Fredi by dispatching it from another throttle connected to LocoNet. Hold Shift + Emergency Stop on the Fredi and the locomotive address is programmed. I tried this out with an UT4 on the Welztalbahn and it worked just fine.

The next time I'll attend a FREMO meet, I can contribute to the meet with a locomotive or two. Meanwhile, the SWD Fredi is a great throttle for the switching jobs on the Welztalbahn where changing of loco address is not required.

Update July 18, 2020:

The other Fredi is now also built.

Experiments: Green Screen

I've been playing with OBS a lot lately. Today I tried something different: use a green screen to spiff up a virtual presentation. Instead of just screen-sharing the presentation, I'd use the laptop camera to film the room with me and a green screen in the background. Using the Chroma Key filter the green screen becomes transparent and shows the underlying window grab from Key Note in the OBS stack.

Here's my test arrangement.

Screen-grabbing video into Zoom or Meet tends to be somewhat problematic, and I didn't get the details right yet. However, getting the weatherman effect is cool and fun. I'm sure, I'll find more uses for this.

SVL: Club evening with remote operator

[ CabCam posts ]

For tonight's club meeting I brought the camera to the layout, so that we could test more of the applicability of this on the actual layout. It worked well.

Here is James running the train on the layout from his home in the Santa Cruz Mountains.

The camera opens up new perspectives for ops. Here's a screenshot taken by another member participating in the video conference.

This time I set up in a much more comfortable location in the layout room.

SVL: Raspberry Pi Zero Camera Car with Streaming Video

[ CabCam posts ]

We're still tuning the software and streaming setup, but the hardware looks feasible.

This is a Raspberry Pi Zero W with the Zero Spy Cam and a Juicebox Zero battery board connected to a 2000mAh Li-Ion battery. A completely self-contained camera setup that easily fits on a HO flat car and can stream video over existing Wifi. If I stack the components more intelligently, it fits on a much shorter car, too.

During the Show&Tell at tonight's club meeting, we demonstrated the setup at the workbench and on the Welztalbahn.

Members on the video conference were able to observe the trip with only a few seconds delay. This worked much better than expected.

So far, so good. The real test will be trying this out at the club.

Experiments: FRS Radio Video Conference Gateway

In normal times, Silicon Valley Lines runs one operating session per month. In these times ... not so much. Density of people in the layout room is the main problem with social distancing. Cutting down on the number of people, wearing masks, proper hand santitation, and keeping social distance is a requirement in these times.

What would it take to have a remote dispatcher patched into the FRS radios used by the engineers in the layout room? Video Conferencing solutions like Google Meet, Zoom, Skype, and others bridge the long-distance connection easily. However, how do I connect a FRS radio to a computer?

Should be easy: Connect the headphone speaker of a radio to the microphone in on the laptop, and the line out of the laptop to the microphone of the radio. Not so fast! The voltage levels between line, speaker, and microphone vary quite a bit. It's not just about plugging stuff together with the correct wires, but rather needs some circuitry to translate the signals properly in both directions.

The next idea I had was to connect a headset to the radio, so that I have physically separated places for speaker and microphone, and tape the microphone of a computer headset to the earpiece from the radio, and the computer ear piece to the radio headset microphone. With a headset plugged in the radio automatically goes into VOX mode when turned on. When the radio "hears" something being said, it starts transmitting. There is a delay of 2-3 seconds before radio transmission starts, so people on the "computer" side need to add a couple filler words to all their transmissions. This worked, but volume level from radio back to the computer side was very low and very garbled.

Eventually I found a setup that works reasonably well. I'm using a new cheap ear piece and microphone for the radio side, and regular earbuds for the computer side. The 4-pole 3.5mm jack of the earbuds goes into a splitter cable that converts the wiring to two 3.5mm stereo plugs. The microphone is plugged into a small external denoise adapter and into the computer. I taped the ear piece of the radio side to the microphone of the computer side, and taped the microphone of the radio side to the laptop speaker. The photo above shows the early test setup using a TED talk on Youtube. The volume on the computer needs to be loud enough that the radio starts transmitting, but not so loud that it overwhelms the radio microphone, but with some experimenting the right level was found quickly. A remote dispatcher (or remote engineer) should probably have a microphone close to his month and not use the built-in microphone of their computer.

Participants on the video conference will be able to see the video feed from the layout room and hear the conversation of dispatcher and crews.

I'm still interested in the proper circuitry for connecting the radio directly to the computer, but that's for another time. In addition, at least my Motorola Talkabout radios don't work if they are plugged into a charger, which makes me really sad.

Experimenting

I'm playing with old smart phones as IP webcams, Open Broadcaster Software to stream video to Youtube Live, FRS radio to computer audio, ... This might be going somewhere useful.

Signal bell boards for the ETE HOm Swiss Narrow Gauge modular layout

Test Setup

Every now and then I'm at shows running trains with the HOm swiss narrow gauge group of the ETE San Francisco Bay chapter.

The operating scheme is straight-forward: The layout is set up with a single track main line, a couple intermediate stations, and staging at each end of the layout. The typical setup consists of staging with a return loop at one end, two intermediate stations, and a simple staging yard at the other end. Operators are positioned at the stations or staging yards and verbally hand-off trains from station to station. A typical conversation between two neighboring stations goes like this:

- "Can I send you another train?"
- "Yes, go ahead. Once that's here, I'll send you a train back."
- "Ok." 

This works quite well. However, problems arise at shows with lots of visitors since the noise level makes communication, or even getting the attention of the other operator, difficult. Especially when the layout is arranged in a way so that they sit with the back to you.

Before the invention of the telephone, railroads in Europe had similar problems. How to tell the following station and all operators at intermediate railroad crossings that a train is on the way? How to do that in a way that works reliably day and night, regardless of weather in rain, sunshine, and fog? Initially, humans were positioned along the tracks and blew a horn to notify the next post that a train is coming. That obviously didn't work very well and became completely inadequate as traffic density increased.

In the mid-1800's bell signals ("Läutewerke") were invented to address this. The Wikipedia article describes the basics. Hans Waegli's book "Hebel, Riegel, und Signale" has a good historical summary as far as use in Switzerland is concerned. The common arrangements were built with two bells tuned to different tones. Each bell was associated with a direction, so that crossing operators can tell when to expect the train and lower the gates early enough based on which bell is ringing. Bell signals were used widely in Germany, and became very common in Switzerland were they lasted well into the second half of the twentieth century, especially on secondary and narrow gauge lines. Some are still in operation today, but only to alert waiting passengers that a train as left the previous station.

I figured we could use a similar approach when operating the HOm layout at shows.

Signal bell boards schematic

Nice two-tone bells are rather expensive, so I settled for a cheap DC door bell. Each station has a button per direction that rings the bell in the next station. Because I only have a single bell, the direction of train announcements needs to be encoded in the ringer scheme. A simple ringer scheme to offer and accept trains between stations could look like this:

2 rings by originating station: Request train move from left to right
3 rings by originating station: Request train move from right to left
1 ring by destination station: Train may come.

If the destination station doesn't want to accept the train, they simply don't acknowledge, or offer a train in turn.

Since this is a modular layout, the cabling length between stations might vary from show to show. RJ45 plugs and sockets make using cables of different lengths easy. For the test setup I used Ethernet cables. Since only 4 wires are needed for the inter-station wiring in the schematic, I mirrored the pin assignments, so that any Ethernet-style cable can be used, and one doesn't need to pay attention to orientation. I tested this today with a 50ft Ethernet cable, which worked just fine.

Intermediate signal bell board

The real railroads used fairly elaborate schemes with two or even only one wire between stations, but those required independent power (mechanical, batteries, or house power) at each station. I wanted to power the whole system only from a single power supply, so had to include a power bus in the schematic.

Signal bell board with power supply connection

The signal boards are clamped to the modules so they can be mounted wherever it is convenient. The left button is connected to the bell of the station to the left, the right button to the bell at the station to the right, so using the bells is very intuitive for station operators.

Signal bell board clamped to the Welztalbahn

The signal bell boards come in two versions (yellow and green in the schematic above), that need to be installed in alternating sequence. So far I built two boards: a yellow intermediate board, and a green board with power supply connection. I have enough supplies to build two more boards which should be sufficient for the HOm layout.

Emsingen Panel Updates

Yesterday I did some behind the scenes work to fix a long-standing problem with the panel. In fact, this problem has been there ever since I added the panel in 2012 (!) The buttons for the turnout into the Lokstation and the two lower buttons on the yard ladder were not connected to anything. This wasn't really much of an issue, the Lokstation turnout was used only a couple times during a session and could be actuated with a mouse click from JMRI.  The Yard ladder buttons are not strictly needed and operators just used the black buttons for the respective turnouts. The reason why they were not connected was that the Team Digital SRC16 stationary decoder driving this panel only has 16 inputs and I have 19 buttons.

Since I now added the button for the route to Untergroeningen (on the far left in the picture above, compare to the panel in the post from 2012), I decided to clean up the other buttons, too. I have a couple Digitrax DS64 stationary decoders installed nearby, which have 4 sensor inputs each. I made a 10 pin header to match the SRC16 sensor pinout and ran a cable for 8 inputs over to the two DS64 decoders. Now I have 3 spare inputs at this panel. Not sure what to do with them, but maybe I'll find a need in the next 8 years...

Since I need to add the new routes from Emsingen to Untergroeningen to JMRI, I decided to also convert Emsingen panel operation to require the operators to push origin and destination buttons at once. This is addressing another source of confusion that occasionally tripped up Emsingen operators. I wrote up how the panel logix works in a post from 2011. The change is very simple: Whenever a button is unpressed, I simply reset the respective internal sensor back to inactive. That way, operators can change their mind after pressing the first button, and there is no state in the panel button Logix when no buttons are pressed.

SVL: Programming Signals in Dayton

After the business meeting today I spent some time with our signal server configuration. I added routes for the two uninitialized signal heads in Dayton, as well as fixed some minor bugs in the routes at the north end of Dayton.

The Dayton panel shows the state of the signals, at least as far as what the computer thinks the state should be ...

... and the signal heads reflect the state, too.