19th-Jun-24, 10:41 AM
This project is taking shape nicely.
In it’s initial 12 car format the wireless hub is reading up to twelve throttle IDs using a frequency hopping method (described earlier) with 8bit throttle resolution and fast refresh rates.
The throttle data is then packaged into a single broadcast data packet which all car decoders receive simultaneously. Each car selects the section of the received data which corresponds to their own specific ID.
Where this will get particularly interesting (IMO) is when PC instructions are added into this signal path. I may be mistaken but I don’t believe any of the current in-market wireless digital slot car systems take this approach.
Here the forward plan is that the PC will send additional commands for each ID which may be any of the following:
1/ pass the data from throttle to the broadcast data packet without any modification.
2/ modify the data from the throttles using fast multiplication. Here the raw throttle data would be modified by the PC which would supply a floating point multiplier with value between zero and one. This should be perfect for simulation including fuel loading, tyre wear, weather and damage.
3/ replace the data with PC generated throttle data. This should add the opportunity for multiple pacer cars similar to what can be achieved with APB-style PC controlled pacer cars.
4/ replace the data with a zero throttle value (with or without braking). This would be for power-down before start or pehaps an emergency stop feature for public events.
As I say, this experimentation is starting to get quite interesting :)
c
In it’s initial 12 car format the wireless hub is reading up to twelve throttle IDs using a frequency hopping method (described earlier) with 8bit throttle resolution and fast refresh rates.
The throttle data is then packaged into a single broadcast data packet which all car decoders receive simultaneously. Each car selects the section of the received data which corresponds to their own specific ID.
Where this will get particularly interesting (IMO) is when PC instructions are added into this signal path. I may be mistaken but I don’t believe any of the current in-market wireless digital slot car systems take this approach.
Here the forward plan is that the PC will send additional commands for each ID which may be any of the following:
1/ pass the data from throttle to the broadcast data packet without any modification.
2/ modify the data from the throttles using fast multiplication. Here the raw throttle data would be modified by the PC which would supply a floating point multiplier with value between zero and one. This should be perfect for simulation including fuel loading, tyre wear, weather and damage.
3/ replace the data with PC generated throttle data. This should add the opportunity for multiple pacer cars similar to what can be achieved with APB-style PC controlled pacer cars.
4/ replace the data with a zero throttle value (with or without braking). This would be for power-down before start or pehaps an emergency stop feature for public events.
As I say, this experimentation is starting to get quite interesting :)
c

![[+]](https://slotracer.online/community/images/bootbb/collapse_collapsed.png)