Well, nearly two weeks ago I tested the S/N board, but since then I've not had a chance to install the mod on site.
And this week looks even busier....
Sunday, 15 November 2009
Tuesday, 3 November 2009
To COS or not to COS - that is the question...
I took GB7MH off-air most of yesterday and today as I tested some new code designed to help with reception of weak GMSK signals. Whilst it was not a total success, I have learnt quite a bit from the testing which I’ve now been able to replicate at home on the test system.
The problem I’m trying to solve is that reception of GMSK should be able to go to significantly noisier signals than it’s FM equivalent. However, at the moment, GB7MH is running on an FM receiver and uses the squelch to detect a “valid” carrier. This makes no sense for GMSK – I should just check for a readable GMSK waveform and decode. But at the moment, I’m gated by the FM squelch.
The effect is that rather than descend into higher bit-error rates for weak signals, the reception seems to cut out from perfect to nothing. The answer is to leave the squelch wide-open and just detect the GMSK modulation on it’s own merit. Then progressively weaker signals should just degrade to a pre-defined S/N point, where I cut-out.
So, I wound the squelch wide open – and caused all sorts of problems, because noise, especially the kind we had with lots of rain yesterday “looks” like GMSK. The effect was long-lived reception of rubbish. I tried several schemes to work around this (counting valid re-syncs in the GMSK, looking for header/end-of-transmission markers), but none really worked, and a sudden spike of noise kicked off a local transmission using the callsign of the last valid station heard. All very confusing.
The solution lies in not using COS, but using a S/N value from the GMSK demodulator. But this isn’t built into the v1 Satoshi board, and I just can't get the v2 board to play nicely.
So, I'm going to build the G4SZM "S/N to COR" circuit and use this to drive the COS pin. Then I can wind the squelch wide-open and just rely on true GMSK traffic.
That's the theory......
David
The problem I’m trying to solve is that reception of GMSK should be able to go to significantly noisier signals than it’s FM equivalent. However, at the moment, GB7MH is running on an FM receiver and uses the squelch to detect a “valid” carrier. This makes no sense for GMSK – I should just check for a readable GMSK waveform and decode. But at the moment, I’m gated by the FM squelch.
The effect is that rather than descend into higher bit-error rates for weak signals, the reception seems to cut out from perfect to nothing. The answer is to leave the squelch wide-open and just detect the GMSK modulation on it’s own merit. Then progressively weaker signals should just degrade to a pre-defined S/N point, where I cut-out.
So, I wound the squelch wide open – and caused all sorts of problems, because noise, especially the kind we had with lots of rain yesterday “looks” like GMSK. The effect was long-lived reception of rubbish. I tried several schemes to work around this (counting valid re-syncs in the GMSK, looking for header/end-of-transmission markers), but none really worked, and a sudden spike of noise kicked off a local transmission using the callsign of the last valid station heard. All very confusing.
The solution lies in not using COS, but using a S/N value from the GMSK demodulator. But this isn’t built into the v1 Satoshi board, and I just can't get the v2 board to play nicely.
So, I'm going to build the G4SZM "S/N to COR" circuit and use this to drive the COS pin. Then I can wind the squelch wide-open and just rely on true GMSK traffic.
That's the theory......
David
Saturday, 31 October 2009
Update - 31/10/09
GB7MH and GB7BM have been performing very well for the last few weeks.
Minor changes to the code in the last couple of days around the database synchronisation:
1) Bug in the "New User" code - when a user is added to the G2 sync_rip database, the Node ID sent is only 7 bytes long - I was sending 8.
2) Change to the way incoming updates are handled. I now run a "SELECT" using the "last_mod_time" before an "UPDATE" in Postgres. This significantly cuts down the number of changes on each update and really speeds the process up.
GB7MH is still surviving with an 800MHz Via EPIA, 4GB CF card and little else. Truly a D-Star micro-repeater.
73 David
Minor changes to the code in the last couple of days around the database synchronisation:
1) Bug in the "New User" code - when a user is added to the G2 sync_rip database, the Node ID sent is only 7 bytes long - I was sending 8.
2) Change to the way incoming updates are handled. I now run a "SELECT" using the "last_mod_time" before an "UPDATE" in Postgres. This significantly cuts down the number of changes on each update and really speeds the process up.
GB7MH is still surviving with an 800MHz Via EPIA, 4GB CF card and little else. Truly a D-Star micro-repeater.
73 David
Monday, 12 October 2009
And the next bug is...
.... not exciting the threads neatly.
I've modified their operation so that any failure is trapped and an immediate pthread_exit is called. This has been working fine for 4 days.
I've modified their operation so that any failure is trapped and an immediate pthread_exit is called. This has been working fine for 4 days.
Wednesday, 7 October 2009
G2 Update/Routing Issues Fixed
Hit some problems today when testing G2 routing and updates "in anger." I was getting issues where the two threads were locking, and causing a seg fault in the code.
The reason appears to be that originally I had the two processes within the main code, rather than running them as separate threads, and I had declared global values which were now used outside of the main body. If one thread access them at the same time as the other - disaster.
So far, so good, but I need to keep a close eye on this one.
The reason appears to be that originally I had the two processes within the main code, rather than running them as separate threads, and I had declared global values which were now used outside of the main body. If one thread access them at the same time as the other - disaster.
So far, so good, but I need to keep a close eye on this one.
Sunday, 4 October 2009
GB7MH D-Star Improvements
Some improvements to the software over the last few days:
1) The way that the re-sync bits are generated has been changed. The entire frame is reformed to ensure that the re-sync pattern (0x55, 0x2d, 0x16) is sent every 21 frames, regardless of the incoming stream. This has eliminated mid-over beeps during G2 and D-Plus sourced QSOs. The same logic has been applied to local repeat which assists marginal incoming transmissions, and to outgoing G2/D-Plus packets.
2) The detection of a valid station on the input has been changed so that only valid D-Star headers will cause the repeater to open. FM/Squelch/Invalid-CRC headers will not open the local repeat functionality and are effectively ignored.
3) Lost sync on Internet-sourced packets. This is a difficult one to crack, but I can now detect and compensate for up to 2 seconds of lost DV frames, in-filling with silence.
73 David - G4ULF
1) The way that the re-sync bits are generated has been changed. The entire frame is reformed to ensure that the re-sync pattern (0x55, 0x2d, 0x16) is sent every 21 frames, regardless of the incoming stream. This has eliminated mid-over beeps during G2 and D-Plus sourced QSOs. The same logic has been applied to local repeat which assists marginal incoming transmissions, and to outgoing G2/D-Plus packets.
2) The detection of a valid station on the input has been changed so that only valid D-Star headers will cause the repeater to open. FM/Squelch/Invalid-CRC headers will not open the local repeat functionality and are effectively ignored.
3) Lost sync on Internet-sourced packets. This is a difficult one to crack, but I can now detect and compensate for up to 2 seconds of lost DV frames, in-filling with silence.
73 David - G4ULF
Thursday, 1 October 2009
GB7BM QRV
GB7BM covering Birmingham City Centre went live with the Linux software yesterday.
GB7MH has been providing excellent service for the last 7+ days with minimal issues.
GB7MH has been providing excellent service for the last 7+ days with minimal issues.
Subscribe to:
Posts (Atom)
