[Dr_C]

With an IR based 36 car detection system in field trials for lap detection and lane changer requests, it’s time to turn some attention to throttle control options for higher numbers of cars.

I’m exploring potential control options and am interested to focus on options which are distinct from current in-market systems. That said, I am keen to retain compatibility with the major brands wherever possible.

One option is to better compress data to achieve twelve car control via track packets i.e. the SSD and D132/124 approach but extended from six to twelve cars. Big thanks to drifter2 for helping to explore this potential approach.

The second option is of course to go wireless and here I am looking into 2.4GHz broadcast methods where a single broadcast message commands up to twelve cars. 

The thinking here is that twelve cars is more than enough for at least 99.9% of the world’s 1/32 slot car tracks. But for racers who desire up to 24 or 36 cars in their races then either two or three broadcast modules could be operated side-by-side with one as the primary device. The broadcast method offers the opportunity for higher power levels and hence better suppression of in-channel noise.

So that’s the plan for 2024… to build both approaches then test and compare their performance.

c

[Dr_C]

The wireless version of the 12/24/36 car system is starting to take shape.

For me the starting point is a frequency hopping algorithm.

The idea of frequency hopping is to avoid signal fade which happens across the 2.4GHz frequency band when the direct line-of-sight signals interfere with reflected signals (for example off nearby walls) leading to poor signal strength. Fortunately these weak spots occur in different physical locations for different frequencies. Hence, frequency hopping solves the problem of signal fade. It has become standard practice in 2.4GHz radio control systems over recent years for example the DSM-X system from Spektrum.

My system approach starts with frequency hopping and adds in 8bit throttle/brake signals with an overall system refresh rate of 100Hz. Each car decoder will receive two signals on different frequencies every 10msec. In addition both of these frequencies hop every 10msec.

And if a decoder happens to power down as it crosses a lane changer, the decoder re-locks onto the first 10msec control frame that it receives i.e. no re-synchronisation delays.

As I say, progress so far is good. I have transmitter and receiver modules running with the above mentioned frequency hopping plus 8bit throttle/brake data which refreshes at 100Hz. 

The terms transmitter and receiver are a bit of a simplification here as both devices do both. Control data flows in both directions every 10msec.

Next I need to embed these algorithms into throttle controller hardware  and in-car decoder hardware.

The hardware to take this to the next level of demonstration (i.e. cars being driven on track) has been built up over recent months. This hardware is ready for the new code :)

c

[Dr_C]

I am pleased to report that the next system development milestones have been reached. 

The system is based on a ‘wireless hub’ which reads individual throttle values from each of the hand controllers and then broadcasts these values assembled as a datapacket which all decoders can then receive. Each decoder responds to its own specific commands within the datapacket.

As mentioned in the previous post, the frequency hopping method is functioning correctly and forms the basis of what follows.

Progress milestone 1: The wireless hub is now correctly reading wireless throttle signals from prototype throttle controllers. So the controller-to-hub link is now up and running.

Progress milestone 2: The prototype decoders are now correctly reading the datapackets received from the wireless hub. So the onward link to the decoders, now, is up and running too.

The next step will be to generate the motor PWM, brake PWM and IR LED strobe control signals within the decoder firmware… and then… the new system will be ready for first trials where slotcars are controlled on-track.

As mentioned  earlier, the control system is being developed for up to 12 cars per wireless hub. Also, there are options for up to three wireless hubs to run side-by-side i.e. up to 36 cars in total.

Lap counting and pit lane detection methods are already in place for up to 36 cars. So it’s all coming together very nicely.

Many thanks for reading this progress bulletin :)

c

[Dr_C]

I guess I have the luxury of designing a brand new 36 car digital system in 2024 without any constraints from legacy commitments. This is a nice starting position :)

First, like many of the current digital slot car  solution providers I have started with the Nordic chipset which implies the Nordic ESB (enhanced shockburst) protocol. And nice it is too.

Nordic offer three data rates and, like many I would prima facia presume the highest data rate is best. But is that the case?

The data rates for Nordic devices are 250kbits/s, 1Mbits/s and 2Mbit/s. 

And it should be noted the 250kbit/s rate is currently being phased out.

In the early days, 250kbit/s was optical because it offered best signal-to-noise hence best range. However with time Nordic have improved the range performance of the 1Mbit/s option. This is now ideal, in my opinion, for current and upcoming digital slot car systems.

The 2Mbit/s option is attractive because it adds double the data rate but there is an important compatibility challenge in that consecutive frequency channels cannot be used due to the signal bandwidth speading across these adjacent channels. This means twice the bandwidth but half the number of available frequency  channels. So for system designers who wish to use adjacent channels this appears to represent zero sum gain.

In my system design I am using 1Mbps bandwidth so that all Nordic channels can be used separately and effectively, including for frequency hopping methods.

I believe this is in line with the prevailing wisdom across digital slot car system developers i.e. 1Mbit/s is optimal and 2Mbit/s is to be avoided.

Enough theory, next let’s see digital slot cars running at track level… i.e. theory into practice :)

c

[Drifter2]

re data rates -  Reading the data sheet always pays off. :)

[Dr_C]

Yes - we live in a world where it is often perceived as quicker to learn by ‘trial and error’.

When it comes to designing nRF based digital multi car systems… careful reading of the instructions/data sheets definitely makes sense :)

In designing a multi-car system (12 or 24 or 36 cars), with 8bit throttles and 100Hz refresh rate (frame rate) and frequency hopping… much of the 10millisecond ‘frame’ is spent switching between transmit and receive modes or changing channel - each involves significant settling times. 

In my prototype digital system these important settling times account for over 80% of the full 10msec frame. Consequently, data transmissions account for less than 20% of the frame - but happily this is more than sufficient to meet my system performance target :)

c

[Dr_C]

   

A set of ten prototype in-car decoders which have been hardware tested and then flashed with prototype 12-car wireless firmware.

The two part device at the top of the photo is a variant of the hardware design where all the normal electronics is on the decoder pcb with the exception of the microcontroller itself. This sits on the larger secondary board, attached by a 16-way FFC ribbon cable.

The two part decoder design is perfect for initial testing of motor/brake pwm function, IR LED function and head/tail lights.

Then, onto the fully integrated decoder boards - these, now, have been connected to slot car chassis - the motors spool up correctly under wireless command, the brakes at 100% are very sharp, the IR LED strobe frequencies are correct for IDs and lane change, and head/tail lights function correctly including brake lights.

Next, the real test… running these new decoders (and their flashed new ‘Decoder Pro’ firmware) on the track. 

As mentioned earlier the wireless approach is built up with up to three groups of 12 cars. Total is 36 cars.

So the trials need to use a group of 12 cars in the first instance.

Ten decoders are ready for these fun trials - and another two need to be built up very soon :)

All of these in-car decoders have been flashed with the channel hopping algorithm and 8 bit throttle control and 8 bit brake control - all running at 100Hz to avoid any driver perception of ‘lag’.

This is system design theory into practice ;)


c

[Dr_C]

   

Here is a technical demo of the radio spectrum output of the wireless hub component of the new 12/24/36 car wireless system demonstrating fast frequency hopping across different channels.

The horizontal axis shows frequency with 2.407GHz at the centreline. For information this corresponds to Nordic channel 07. Lower channels are to the left and higher channels are to the right.

The six signal peaks in shot correspond to hop channels. The decoders lock onto these signals and at any point in time they will use the stronger signal peaks for slot car control.

In the (future) full system implementation these peaks will be more widely distributed across the available 2.4GHz spectrum.

Thanks for reading :)

c

[Drifter2]

Clever stuff 

[Dr_C]

Thanks Drifter - it’s all working surprisingly well, so far, both the wireless hub and the observation method using the 3GHz spectrum analyser.

The setup I used picked-up the wireless signals ‘off air’ using a small antenna on the input hence the relatively high level of background noise - especially towards the right side of the photo. The spectrum is of course shared with other devices such as blutooth and WiFi devices which all have potential to create channel noise.

As per the photo the analyser is continuously scanning from 2.401GHz to 2.413GHz in small increments.

The wireless hub is frequency hopping and only sending out very short ESB payloads. Consequently the signal capture process is hit-or-miss depending on whether the hub is transmitting on the same frequency as the current value of the spectrum analyser’s frequency as the scan/sweep progresses. Hence the statistical nature of the profiles shown. I should also add, the analyser is set to ‘hold peak value’ mode so the scan pattern builds up across multiple scans/sweeps.

Hope the above makes sense :)

c