I believe that's for the protocol between the MyLaps decoder hardware and race timing software. The current issue is to be able to decode (be compatible with) the new RC4 ("three wire") transponder signals.

https://cimg8.ibsrv.net/gimg/www.rct...0c936172a4.png
In the past weeks I'm working on a timing/scoring application, LapBeeps. It is free to use, but it's not open source. The target audience is the same as OpenStint/RCHourGlass/LapMonitor. The only supported decoder now is OpenStint, but more to come. There is a demo decoder built-in though if you want to try it. The project was made in quite a hurry, in a function-over-form mindset, so expect a rough beta-version. It can sync online, a feature I'd like to commercialise eventually; note though, this is purely a convenience feature in case you don't want to share the screen or bring a printer to print the results.

Contact me in private if you have any question/feedback.

Backstory: I contacted several vendors of such software to integrate with the openstint decoder. The only reply I received was an automated mail from LiveTime, offering me MyLaps decoders at an unbeatable price :). I happen to have some time now, so decided to YOLO build something. I'm not completely delusional, I know this market is full of dead projects and failed companies...

Hi,

I just want to contribute some first test results with this project.It is still artificial testing in my basement, not real-world, but it gives some impression.
I built a motorized 4-arm round-about, carrying two hybrid transponders and two hand-wound hourglass transponders. I placed this at the far end of the loop (2,50m x 25cm, terminated with 320Ohm), so that the transponders swing in and out of the loop, when the round-about is moving. Long story short for the impatient: I collected +4000 laps in +2h run-time for each transponder with no lap missed and I am absolutely amazed that it is possible to get such a setup running just by installing SW and plugging cables.

Here is some more data of the setup:
- RTL-SDR v4 (claims original version)
- No pre-amp, just the (cheap) balun and then the RTL-SDR v4 right after it, about 5cm SMA cable, 2m USB extension between RTL-SDR and laptop.
- The transponders are somewhere between 5-7cm above the loop. The arms are a bit shaky...
- The round-about turns with a period of about 1,9sec, arm length is 40cm. That gives the transponders a moving speed of about 5 km/h
- In fact the transponders are placed such that they cut in on one long side of the loop and out on the far-end short side. Idea was to further reduce overlap and time inside the loop.

Some data for the decoder
- running on Windows 10 based laptop
- I used the special rc4 test built with the rc4 data of the hybrids trained. But this didn't make any visible difference other than the decoder confirmed the loading of the files at startup.
- starting without any parameter, so default gain of 20db
- Connected to zRound via bridge
- noise power avg -42,3
- DC offset 0,9
- frames processed vs. received avg 59%
- The two hourglass transponders have an RSSI of -22,8 / -20,9 and a hit count of 65 / 78
- The two hybrids have an RSSI of -15,3 / -14,7 and a hit count of 146 / 125

While I believe the hit count is ok, I wonder, whether I should increase the gain a bit to have more buffer for weak transponders placed up high in the car at some strange angle...
I see the hits going up and down when I change gain, but did not yet monitor the processed_frames ratio.
First real-world try-out will be coming friday.

Thanks for the feedback!

On rtl-sdr, you can experiment with the gain pretty much freely, it is hard to overwhelm the frontend. On a hackrf, for comparision, too high rssi cause the decoding to fail much earlier. The gain scale is meant to be in decibels, so setting it to 25 should result ca. 5 dB better rssi. I don't like seeing higher rssi than -5 dBFS, and try to setup for -10 dBFS with a well-placed transponder.

With your setup, if I understand correctly, given the small size, not going out of the detection window can be an issue. This can be an upper limit for the gain.

With the rc4-build, the frames detected/processed somewhat lost the meaning, as a lot of rc4 frames are dropped on purpose (not being in the repeating set).

Good morning, great project! I've already made the rchourglass and it works perfectly. I want to test this one now, but I have some questions.

Do I necessarily need a Raspberry Pi? Or can I use, for example, an RTL-SDR directly on the PC?

Another question: is it possible to adapt the project to read kart transponders?

A laptop is fine. You can download the Windows binaries from Github.
https://github.com/zsellera/openstin...latest-windows

Unfortunately I do not know anything about karting transponders, maybe others can help out here. However, I'm pretty sure both the openstint & mylaps rc transponders are detectable when mounted parallel to the ground on a gokart's or bicycle's frame (worst case increase the wire separation in the pickup antenna to 30-40 cm).

Hi,
here is some feedback from using the system at our last club night.
Setup as written before:
- Loop 2,50x0,25m, terminated with 320Ohms, Balun, no preamp, RTL-SDR, windows laptop. zRound via zround-bridge
- Indoor carpet track, loop under carpet. we race 1/10 touring cars, all plastic tube chassis.
- We had about 15 active transponders of various types. Some cars even equipped with two transponders within 5-10cm distance, just for testing: RC4 hybrid, pure RC4, hand-wound hourglass, PCB-based hourglass.

Generally, we had no SW stability issues with any parts of the system. No crashes, no hang-ups.
Learning the RC4s worked like a charm. The fact that the recorded rc4 file is monitored and auto-reloaded the moment you change the file name to the real transponder number is a wonderful detail.
Detection sensitivity was also very good. At some point, we suspected a missed lap and raised the gain from 25 to 30, but in the end the problem was elsewhere.
I piped the decoder output into a file for later analysis. The variation of the signal strength in that real-world scenario is even higher than in my previous testing:
At a gain of 25 there are transponders at -36db and 4 hits while others are at screaming -7db. Noise floor still at -42.
When moving to gain 30, the loudest transponders are -2db. But this also appeared to work fine. So probably, I will settle somewhere at 27 dB gain plus some instructions for the drivers, where to place the transponders :-D

So again: very robust detection. You have my vote. :-)

Good morning, thank you for your reply.

Kart transponders operate in the 3.57 MHz band. I have some here; I'll take some images of their signal on the oscilloscope and send them. If I could get more information, it would be great if the project worked for both RC and karts.

The RC4 learning feature is now available with disq's verification scheme on the master branch. Thanks the help from everyone.

Upgrade to this latest release, as the previous one had a bug in timing :o
https://github.com/zsellera/openstin...nightly-master

Nice, one question (I've not read the full code). Beside CRC checking of the packets, do you 'learn' them by counting the most frequent ones?

Oldfan proposed/demonstrated a "just put the car near the loop and let things happen automatically" approach.
1. Waits the signal to stabilize, then starts the learning process automatically
2. It collects 8196 rc4 transmissions. During my tests, this amount was just enough to collect every repeating message from an RC4Hybrid.
3. If you move the car or someone else crosses the loop, the learning is interrupted (rssi moves out of a 3dB window)
4. either interrupted or finished successfully, there has to be a 1s silence to re-arm the state-machine for the next car

There must be a repeat for a packet to be remembered (saved). All packets ever seen repeated are saved (even if it was repeated 2000 times or just 2).

RCGTIMING.COM SUPPORT!

https://cimg4.ibsrv.net/gimg/www.rct...d9b148e14d.png

This is an online timing application. There is a new "bridge-rcgtiming" to stream the decoder's output to their backend. On their web interface, register a decoder, and click "Driver App" download. Download only the "Configuration update"; the details on the download screen won't matter later. There is a human-readable "main.conf" in the zip file, and an authentication token inside. The bridge-rcgtiming is asking for it (enter without the quotation marks).

https://github.com/zsellera/openstin...e-rcgtiming.py
Part of the windows distribution (.exe); the rest of use can run the python script.

Just to confirm:
The format of the .rc4 files changed and the transponders have to be relearned?
At least I don't get the "Loading transponder..." message when I copy the previously recorded files into the folder and the files look different inside (less data).

Try again please with today's version, it should load the previous files as well. The files produced during the collision-experiment contained 28-byte long lines (the full 112 bit payload). The current implementation saves only the useful 64 bits (16-long lines). The old format still holds the information required. Windows use "\r\n" line-termination scheme, but I'm working on a Mac (but testing files produced on Windows) and this "\r\n" problem went unnoticed. It should be fine now.

Hi,
Great project! I'm looking for something similar for club members who just want lap times and aren't racing. I already have a MyLaps timing system for those with MyLaps chips, with lap times uploaded to our website. I have a second backup loop on our tracks with a 1:9 balun. I'd like to install your system on my second loop.
So, what exactly do I need? A Raspberry Pi, or would a Debian VM (with USB capability) work?
Do I need a HackRF One box or RTL-SDR v4 connected to the loop and via USB to my VM?
And that's all?

Another question about your "Nightly transponder-v2" schematic on GitHub. On version 2, you replaced it with an ATtiny816; what did you use to program it? The Adafruit UPDI Friend - USB Serial UPDI Programmer seems to be made for the attiny 816 according to the description.
On JLCPCB it's an ATtiny 816, but when I look at the firmware code it's for ATtiny 1616. Which one should I use?
The same applies to the crystal in the BOM; it's a 10 MHz crystal, and in the code we see:
FUSES = {
.OSCCFG = 0x2, // 0x02 = 20 MHz
};
Do we need to make a change here as well?

My goal is to retrieve the transponder numbers and then send them to my website via an API. Is that possible? I saw that it's possible to monitor the data on port 5556.

Thanks for your answers.

Hi,

You need a laptop only. Longer version: any host computer can work, including a raspberry pi. When the thread-starting post was made, I used a Raspberry - such a setup mimics a "real decoder box" with network access. For a typical use-case it's overkill though, as you need a laptop for lap counting anyway.

Exactly. Go with the rtl-sdr v4, as it's much cheaper than a clone HackRF. While the HackRF shows better low-SNR performance, it' not noticeable in practice. The next-best upgrade is a 4-6 MHz filter after the balun, but you have to DIY one, as it's not an off-the-shelf component.

The v2 is in prototyping phase for now. Compared to the master branch, it offers 1S-battery support, voltage-independent output level, higher signal strength and easier tuning. The firmware was tested so far with attiny1616 only, but I expect it to work down to 416. I received the latest version (what you see on github) last week, hopefully I can test them this week. It works with a 10 MHz external oscillator (crystal+driving in the same package). The OSCCFG is a leftover from testing the internal oscillator, which can work both at 16/20 MHz (hence the FUSE config). Unfortunately the internal oscillator is not accurate enough for this application. No change is needed, the firmware switches to the external oscillator.

Check out the integrations/ folder for references, notably bridge-ws.py and bridge-http.py. ChatGPT/Claude can generate great starting templates, just show them the documentation.

C2880033 shows 12337 pcs in stock.

I did not verified C654980 yet, but it is probably a more stable alternative with 18 pf shunts than the original part (original comment).

Thanks for all the replies, I'll wait for you to confirm the v2 transponder. It's already in my cart on JLCPCB with all the components.

I don't need software to count the laps; if bridge-http allows me to retrieve the transponder number (apparently possible given the code), my website handles that. I already do it with my MyLaps decoder. => h*ttps://cpbvrc.fr/comptage/

Hello,
I'm interested in making a decoder for a local track and have a couple questions.
Has anyone tried to make it work with an official amb loop ? The track already has a loop installed so I'd like to take advantage of it.
Would it run fine on a raspberry pi3b (not 3b+) ?

Thanks !

This is absolutely outstanding. Going to make one here shortly. Amazing work!

The loop should work fine. There is a 75 ohm bnc male connector on the mylaps cable. You need a bnc-to-sma adapter to connect it to an sdr. The 75-50 ohm bnc connectors mate fine without damage.

I did not test with rpi3b. The decoding process requires both usb i/o and cpu, and b+ improved on both over model 3b. On a b3+, the cpu usage is about 40% of a single core, so I'd expect a 3b to work just as well. Note though, you can use the same host computer which runs the lap counting software. On my 1.7 ghz intel cpu from 2013, the cpu usage is less than 3%.

I ordered a RTL-SDR V4, SMA to SMA RG316, and a 9:1 Balun from aliexpress. Can't wait to give this a shot. Do you sell the pre-amplifier boards? Is it best to go through PCBWay or JLPCB?

V2 TRANSPONDERS TESTED AND VERIFIED

Thank you everybody for your patience. From now on, the v2 transponder is the primary version you see when visiting openstint-transponder. The previous version is available in a separate branch (v1).

Highlights:

• similar signal level to an RC4Hybrid
• works down to 2.8 V supply rail
• flat signal level down to 3.4 V (miniZ and 1S-battery is support)
• much easier to tune, less harmonics, symmetric sidelobes

The new design was tested with ATtiny 816/1616 and 3217. I'm certain it runs on 3216 and 416 as well.

MEASUREMENTS

Signal strength (blue: RC4H; yellow: OpenStint v2; same distance)
https://cimg5.ibsrv.net/gimg/www.rct...8a5ade31b8.png
Bit transitions:
https://cimg6.ibsrv.net/gimg/www.rct...43ef5a3fc3.png
Occupied bandwith:
https://cimg7.ibsrv.net/gimg/www.rct...93c83b9929.png

TRANSPONDER PANELS FOR SALE

I have now multiple panels which I'm offering for sale. Each panels are programmed and tested with the latest OpenStint firmware. 30 EUR/panel (8 pcs transponders). I'll send them as a regular, sub 50-g mail. Shipping costs are about 5 EUR when sending untracked, and 10-12 EUR when sending tracked. Contact me in PM for details.

Note: this deal works only if you need 1-2 panels; for larger quantities, go to JLCPCB.

WHAT'S NEXT?

The transmit antenna is on L2-L3, leaving the bottom layer free for a 3rd loop. I think this transponder can be smaller when the bottom layer is utilised as well. This time I'd like to get rid of the 10 panels I have before spinning a new version though.

PS. savage24x: you're good with the HF balun, the preamp is a nice-to-have. I have a single piece left from earlier prototypes, contact me in private.

Hi,

I am trying to understand the transponder ordering & flashing process via JLCPCB. I tried to place the order via the web user interfacel.
- Delivery Format option:
If I choose single PCB I get a error message about duplicates later after uploading bom and pos files. I could instruct to ignore it, but not sure whether that is right.
If I choose panel by customer (which also sounds about right), I am asked to enter dimensions. When I enter 2 columns 4 rows, I end up with a total cost, that is above 600 USD. Doesn't sound right either.

- What are you recommending as surface finish option?

- Flashing the firmware:
I think I can take the easy way and skip the build process and directy jump to flashing the Main.hex file from the release package using the STM32CubeProg tool linked earlier in the thread (although avrdude is mentioned in github)
However, what hardware do I need to connect to the transponder? Do I need a full Atmel ICE kit? Google returns a huge range of devices.

Thanks a lot!

You need something that can flash UPDI. Easiest option is to get one of these, https://www.adafruit.com/product/5893
(in fact you can make a basic updi programmer yourself using a resistor if you have another programmer lying around but it's fiddly if you haven't been around the block)

1. DOWNLOAD PANEL, BOM AND POS FILES FROM GITHUB

Go to the recommended release linked from the readme, and download the "panel-release.zip". Inside, there are:
- gerbers.zip: this describes the various layers for manufactoring
- bom.csv: a list of components to source for the assembly
- pos.csv: the position and orientation of the aforementioned components.
All of these files must be read by the manufacturer, you're not supposed to have anything to modify on them.

2. GO TO JLCPCB, REGISTER, AND "ORDER NOW"

First, you have to specify the PCB parameters. Important settings are set automatically on gerber upload. You have to change:
- delivery format: panel by customer
- panel format: 2x4
- PCB Thickness: 1.2 mm (important!)
Do not change anything else. For surface finish, HASL is good enough. Lead-based soldering is easier to prototype, and compliant/legal for diy purposes. Lead-free also works (melts differently at higher temps though).

Also tick the "PCB assembly" toggle. Defaults work fine.

https://cimg1.ibsrv.net/gimg/www.rct...c62a78249b.png

https://cimg2.ibsrv.net/gimg/www.rct...73b9df0709.png


3. SPECIFY PCB

1. verify top side was selected
2. upload POS & BOM; select "complete file, ...", JLC has nothing to do
3. BOM screen: is something is out-of-stock, you'll stop here. otherwise proceed
4. Component placement: there is a dot next to all components on the silkscreen (white drawing). Verify components purple dot aligns with the white dots. The LED's negative side is towards the MCU. You can correct if something is wrong.

With lead-free specs, 5 panels:
https://cimg4.ibsrv.net/gimg/www.rct...0fff2701f2.png


4. Save to cart, specify shipping, apply coupons, pay your taxes, etc.

Hi,
Thanks for the work, and it's great to be able to easily order from JLCPCB. We still need to figure out how to program the ATTINY. Earlier, we mentioned the Adafruit High Voltage UPDI Friend, but I see it only has one UPDI pin, so do we just connect GND, PWR to VTG, and UPDI to UPDI?
Is there a place in the transponder code to change the number?

Thanks

In the 3V mode, this should work:
GND->GND
PWR->VTG
UPDI->UPDI
This scheme relies on the reverse current protection of the voltage regulator. I'm programming them this way.
(The atmel-ice does not provide power to the board, VTG is meant for Atmel-ICE to find the voltage of IO lines; I just supply +3.3V externally to VTG as well).

The transponder number is generated from the serial number of the MCU. You can override it.

Hello,
First, I can confirm it works on a Pi3B (not +) as you expected ! Also, it seems to work fine with an amb loop on a large outside track.
After some testing at home with the decoder, I have a weird issue with an RC4 Hybrid that is not recognized. My setup is RTL-SDRv4, Pi3B, and a shitty loop with a 1:9 balun.
I tried a MRT and 2 RC4Hybrids, and one of the hybrid is entirely not detected. The two other transponder work fine, with occasional ghost transponders detected. I checked with my usual RCHourglass decoder and the problematic hybrid works fine, signal quality is identical to the other. I tried monitor mode : no frames. I tried increasing and decreasing the gain a bit, but no improvement. Same on PC. Only the ground noise increases in the status messages when the transponder is close to the loop (otherwise around -42)
Any idea ? Undetected transponder ID is 6215277, if that can help.

Thanks !
Jean

Please do a packet capture of both problematic transponders separately. You should have the rtl-sdr command line tools installed. Run this:

It captures 5 seconds worth of (12.5 million) samples around 5 MHz at 2.5 MSPS. You'll end up with a 25 MB file, compress it and send me for further analysis to [email protected]; Please send the output of "openstint_rtlsdr" as well (from start to the first status message).

---

I'm wondering what the problems can be...

While ghost detections are possible, they are extremely unlikely. There has to be a bit error which passes error-checking, and the same erroneous message has to appear twice to get reported as a passing. Possible, but unlikely. I think the decoder misinterprets a status message as a normal message somehow.

Transponder not detected at all: huhh... I've seen similar phenomena twice so far.

Firstly, too much gain overdrives the frontend, and symbols interleave with each other. In such conditions, preamble detection is not possible. The solution is easy (decrease the gain). There is a tutorial on finding a proper gain with SdrAngel.

Secondly, it is possible that the transponder's clock is off by a good amount. The clock source on MyLaps transponders is extremely inaccurate, and they typically drift downwards in frequency as they age. If the frequency is off by ~19 kHz, detection is not possible (you'll see the exact phenomena as you describe).
There is this line; try recompile with different values (ie. 5MHz-10kHz = 4990000), maybe it helps. @Oldfan suggested this fix long time ago anyway :p

Indeed, that seems to be the reason. I used a scope to measure the frequency of both hybrid transponders, the one that works is exactly on 5MHz, the one that doesn't is closer to 5.03MHz. Also its signal is a bit distorted (looks a little bit like a sawtooth).
It's quite an old transponder, and surprisingly its frequency is on the high side rather than low, I double checked that.
I'll try the fix and try to save the signal of both working transponders ;) The ghost transponder numbers are always the same, ie each of my two working transponder appears as 2 different IDs : its true ID, and sometimes a second "fake" ID as well.

Huhh, a 30 kHz offset is pretty insane.

Up to this point, I discouraged everyone to play with the preamble-detector's thresholding. In your case, a less conservative value (like a fixed 0.6) can be justified. It can detect 30+ kHz offset for *some* packets (depending also on noise). If you're running in monitor mode (-m flag), it reports the guesstimated frequency offsets (FREQ:).

I'll experiment with alternative preamble detection techniques as well.