Hello, and welcome to the forum.
It should not be too difficult to adapt the code written by Mike McCauley, that I presume you already have, to suit the 'SH8 device. Of course you will need to alter vw_setup() to suit the HCS08 timer, presumably a TPM channel, to generate the sampling rate. Additionally, the various pin allocation functions will also not suit, but I cannot see a disadvantage in using fixed allocations within your code for receiver input, transmitter output, and PTT control. And the ISR function would also need modification to suit CodeWarrior.
The code sample seems to mostly assume a RF bit rate of 2000 bits/s (166.7 bytes per second after decoding), but the noise detection process within the receive algorithm requires sampling at eight times this rate, i.e. a timer interrupt every 62.5 microseconds.
For a trimmed bus frequency between 16MHz and 20MHz, this would give a period of 1000 to 1250 bus cycles between interrupts. The ISR code needs to be completed in considerably less than this period. With the rather complex code within vw_pll(), the receiver sampling function, I am not sure whether this is feasible. If not, you would need to reduce the RF bit rate.
I do have some gut held reservations about the robustness of the signalling when using on-off keyed (OOK) modulation. I might have preferred a self-clocking arrangement, such as Manchester encoding, or perhaps a PWM scheme. These can also potentially require a lower number of samples per bit, but do have a greater number of RF transitions.
A characteristic of OOK receivers is that, due to the action of a "bit slicer" circuit, and its minimum threshold level, when the received RF level reduces toward the threshold limit, the decoded pulse width will become narrower. Depending on the modulation scheme and the decodeing method, this may impose a sensitivity limit, rather than the noise level. Typically, the pulse narrowing effect will be worse on receivers that have less noise outpur in the absence of a signal.
With a maximum packet payload of 27 or 30 bytes, the use of a 16-bit CRC might seem excessive - I would have thought an 8-bit CRC would suffice. In practice, I would probably restrict the packet payload to about eight bytes.
Regards,
Mac
