My first real exposure to RS ECC was when I had to reverse-engineer a hardware ECC. There's plenty of material out there, and I spent a significant amount of time reading through various articles, but IMHO the maths/theory really got in the way of understanding what actually happens, i.e. all of them talk about finite fields and polynomials and such, but almost none answered the main question I had: "what does this mean for the bits and bytes I'm looking at?" Furthermore, there is also a scarcity of material discussing RE of RS (i.e. finding the parameters used.)
Eventually I came across https://en.wikiversity.org/wiki/Reed%E2%80%93Solomon_codes_f... which was really enlightening, and I wrote some code to essentially bruteforce combinations of generator polynomials and bit/byte ordering --- and luckily discovered the details of the implementation on the first try. (The first polynomial in my list was 0x211, and it was the right one.)
The final implementation turned out to be relatively straightforward, less than 250 lines of C for a correcting decoder including the unusual (but probably trivial/circuit-simplifying) bit permutation/expansion scheme the original hardware used. The core algorithm itself is mostly composed of XORs and table lookups. I believe I used BkM and Forney for the correction part. If anyone is curious, I'll see if I can find and release some of the code I used.
Do you still have that bruteforce code? I've been trying on and off to reverse engineer the RS ECC in Chirp, a (now discontinued) app for sharing tokens over speaker/microphone.
A few references I've found suggest that is RS(9,5) and might not actually be using GF(32); although you have 18 "symbols" of 90 bits total, with 50 bits of data and 40 parity, I doubt those are the actual RS symbols.
In fact, those parameters line up with 9 * 10-bit symbols in each block, 5 10-bit data and 4 10-bit ECC. I would try a shortened RS(1023,1019) in GF(1023), taking pairs of the 5-bit "symbols".
Here is the code I originally used. I was bruteforcing a non-shortened RS(511,503) in GF(511) which had a somewhat complex transformation between bytes and symbols, fortunately partly documented at the time:
Eventually I came across https://en.wikiversity.org/wiki/Reed%E2%80%93Solomon_codes_f... which was really enlightening, and I wrote some code to essentially bruteforce combinations of generator polynomials and bit/byte ordering --- and luckily discovered the details of the implementation on the first try. (The first polynomial in my list was 0x211, and it was the right one.)
The final implementation turned out to be relatively straightforward, less than 250 lines of C for a correcting decoder including the unusual (but probably trivial/circuit-simplifying) bit permutation/expansion scheme the original hardware used. The core algorithm itself is mostly composed of XORs and table lookups. I believe I used BkM and Forney for the correction part. If anyone is curious, I'll see if I can find and release some of the code I used.