The initial reading and instream syncronization might be improved with some timer run control commands. The timer is actually running after initialization, and the TCNT value can be undetermined at the time you receive the external signal detected interrupt and then attach the timer interrupt. It's not certain where in the bit period you are actually reading the data.
if (signal_detected) {
Timer1.restart(); //will reset TCNT1
Timer1.attachInterrupt(sample_ISR);
signal_detected = false;
}
I also think that the timer interrupt will read the second bit received. The first HIGH is on the RISING interrupt for the signal detected, so if there is an inititial 1-0-1-0 pattern the timer interrupt should always start with a 0.
EDIT: with the inverted readings, maybe the first timer interrupt value will be a 1 if reading a LOW.
data[counter] = !bitRead(PINE, 4) + '0';
Thanks for pointing it out. Resetting the Timer1 before attaching an interrupt made things better but didn't fix everything.
The real problem was in not detaching the external pin interrupt while the timer interrupt was running. Once I detached the external pin interrupt everything went smooth.
Another problem that happened was that after re-attaching the external pin interrupt, it automatically got triggered since the external interrupt flag register was still "active" from before when it first got triggered.
I fixed this issue by setting a bit in EIFR for the specified external interrupt.
I now tried around ~20 samples in a row and the program didn't miss a single bit. 
Looks like it really is stable now, will report back after I make some more tests.
1 Like
Okay, I now have a question about the protocol itself. If I remember correctly, someone here actually worked on pagers and POCSAG protocol?
I'm in the decoding phase of the project right now and my head hurts from the 20-bit data space in a codeword with 7-bit ASCII characters. -.-"
In the first codeword, there is only 6 bits of space for the last character, which means that the first bit in the next codeword belongs to the last missing bit from the previous codeword... which now leaves only 5 bits of space for the last character in the second codeword. Are the first two bits in the third codeword the missing bits for the second codeword and so on? I'm asking because I get strange parity errors when this happens... The amount of 1's in partiy bits from the third codeword is even but the parity check bit is set to 1.. so in total, all 1's together result to odd... which is strange but all data is actually correct, I get the correct message if I decode by hand.
Can someone explain?
I didn't work on the coding/decoding - I was the RF guy - but the extra bits are for forward error correction.
Check out Hamming codes - a very early approach to this problem
This gives you lower error rates than an uncorrected datastream at a given signal - to noise ratio.
You thus sacrifice data throughput for greater range. The difference between the coded and uncoded signal's s/n ratio for a given error rate is known as the coding gain. And the ratio of data bits to the total number of bits sent is known as the 'rate'. The smaller the rate the worse signal - noise you can tolerate, but the smaller the amount of data you can send in a given time. Eg 2G phones have rate 1/2 for their audio.
Mobile phones / uwave datalinks / satellite comms , (and indeed CD's) etc all use such techniques.
How else do you think that NASA probes beyond the solar system with very limited power can send back clean pictures? With very low rates - perhaps 1/1000 or lower.
Allan