14 Nov
2014
14 Nov
'14
1:11 p.m.
Does anyone have a simple GRC for RX conventional Phase 1 audio? The larger program I am
working on is in C and I just want to make sure I have the Gnuradio graph right and tune
it before I hard code it into C. It monitors a SmartNet II system, so I don't need
Phase 2 or Trunking.
If not, is it best to look at the scope.py app in OP25-repeater to figure out what the
best blocks are to use for decoding?
I am trying to switch over from gr-dsd so everything will be more native.
Last dumb question, is it better to use the receive blocks in op25 or op25-repeater.
Thanks!
16 Nov
16 Nov
4:21 p.m.
yeah, was chatting with Jonathan Corgan at the 2014 GNU Radio Conference, and he also
pointed out that OP25 doesn't play very well with GRC. Would be nice to have access
to unlimited free time to work on this :)
My own viewpoint is the existing OP25 GR blocks are not the right level to target for GRC.
Instead we need to wrap them into some new python hier blocks (TX&RX chains,
vocoders, monitoring sinks etc.) using standard existing GR interface conventions that
would in turn be exposed via XML files to GRC. Also a lot of the code in scope.py needs
to be broken up along the same lines... Currently the way that it switches between the
two major P25 demods (FSK4 vs. pi/4 DQPSK) is less than ideal, but it should be more or
less correct (given the limits of what's currently known about correct P25
demodulation).
Can't comment on gr-dsd as I've not studied it. As far as the question about the
op25 vs. op25_repeater code the answer would depend entirely on your definition of
"better" :)
Best
Max
17 Nov
17 Nov
1:04 p.m.
Thanks - I wanted to make sure I wasn't missing an obvious directory full of awesome
grc files. I have been playing with the OP25.grc file that goes with gr-baz. I doesn't
seem to be playing the signal I am playing back from a File Source. The Quad Demod looks
like it is producing four solid signal lines, but there are no dibit coming out of
op25_4fsk_demod
If anyone has the time, could you take a quick look at this C file? It is supposed to
receive a Freq and start recording when Activate() is called and save the wav when
deactivate() is called. It works, but the wav file is silent and really large. I am sure I
am doing something really dumb. If you spot anything, I would be grateful!
https://github.com/robotastic/smartnet-recorder/blob/3.7-P25/logging_receiv…
https://github.com/robotastic/smartnet-recorder/blob/3.7-P25/logging_receiv…
- Luke
19 Nov
19 Nov
4:44 p.m.
if you're getting 4 solid symbol lines but no decode this usually means the decoder
was not able to locate a frame sync (FS) sequence in the demodulated dibit stream. The
most common causes of this are due to anomalies in reception, which can be sorted if you
check the dibit stream for a few of the common ways the FS can get mangled (all sequences
shown are hexadecimal)
0x5575F5FF77FF - normal FS
0xffdf5f55dd55 - signal is inverted (common when using a disctap, due to the superhet
principle)
0x001050551155 - frequency incorrectly tuned 1,200 Hz too low
0xFFEFAFAAEEAA - frequency incorrectly tuned 1,200 Hz too high
0xAA8A0A008800 - frequency incorrectly tuned (error is +/- 2,400 Hz)
All of these errors are more or less quasi-hardware related. The inverted FS should be
caught (depending on which software demod you use) and is usually only an issue with
hardware receivers and the latter three errors are a consequence of tuning error when
using the DQPSK demod, suggesting a need to tighten up your frequency correction (a.k.a.
PPM, offset, calibration, etc).
Max
23 Nov
23 Nov
4:49 a.m.
Thanks Max - What is the best way to check the dibit stream? Is it to dump to raw? This
would be in between fsk4_demod_ff and the slicer?
I think I have something much funkier than mistuned input though. The wav file I am
recording off of the gr::op25::decoder_bf decoder block is really long and large. Like
30Mb for 30 seconds of recording. When I open the wav it says it is ~30 minutes long. This
happens both in GRC and my C program. Any ideas on what could possibly cause this? The wav
sink is set for 8000hz and 16bit.
This is the graph I am using. Is there anything glaringly wrong, if I am feeding it a
good signal?
float symbol_rate = 4800;
double samples_per_symbol = 10;
double system_channel_rate = symbol_rate * samples_per_symbol;
double symbol_deviation = 600.0;
double prechannel_decim = 80; //floor(capture_rate / system_channel_rate);
double prechannel_rate = floor(capture_rate / prechannel_decim);
double trans_width = 14000 / 2;
double trans_centre = trans_width + (trans_width / 2);
prefilter = gr::filter::freq_xlating_fir_filter_ccf::make(int(prechannel_decim),
gr::filter::firdes::low_pass(1.0, capture_rate, trans_centre, trans_width,
gr::filter::firdes::WIN_HANN),
offset,
capture_rate);
unsigned int d = GCD(prechannel_rate, system_channel_rate);
double small_system_channel_rate = floor(system_channel_rate / d);
double small_prechannel_rate = floor(prechannel_rate / d);
resampler_taps = design_filter(small_prechannel_rate, small_system_channel_rate);
downsample_sig = gr::filter::rational_resampler_base_ccf::make(small_prechannel_rate,
small_system_channel_rate, resampler_taps);
double fm_demod_gain = floor(system_channel_rate / (2.0 * pi * symbol_deviation));
demod = gr::analog::quadrature_demod_cf::make(fm_demod_gain);
double symbol_decim = 1;
for (int i=0; i < samples_per_symbol; i++) {
sym_taps.push_back(1.0 / samples_per_symbol);
}
sym_filter = gr::filter::fir_filter_fff::make(symbol_decim, sym_taps);
tune_queue = gr::msg_queue::make(2);
traffic_queue = gr::msg_queue::make(2);
const float l[] = { -2.0, 0.0, 2.0, 4.0 };
std::vector<float> levels( l,l + sizeof( l ) / sizeof( l[0] ) );
op25_demod = gr::op25::fsk4_demod_ff::make(tune_queue, system_channel_rate,
symbol_rate);
op25_slicer = gr::op25::fsk4_slicer_fb::make(levels);
op25_decoder = gr::op25::decoder_bf::make();
op25_decoder->set_msgq(traffic_queue);
wav_sink = gr::blocks::wavfile_sink::make(filename,1,8000,16);
11:08 p.m.
Actually - never mind... I switched to op25-repeater and it seems to be working better.
The only problem is that audio is pretty screwed up:
http://openmhz.com/call/54724f20b993ae114fafa996
http://openmhz.com/call/54724f20b993ae114fafa996
Any obvious things that are wrong? I am converting from short to float and then
multiplying by 1/32768, like scope.py.
Am I not feeding it to the wav_sink correctly or is the problem further up the line?
24 Nov
24 Nov
3:14 a.m.
And here is a snapshot of some of the verbose output I am getting. Is the error rate too
high? Any thoughts on why the ALGID keeps moving around? Should it stay fixed?
NAC 0x3D2 DUID 0x5 len 864 errs 0
NAC 0x3D2 DUID 0x5 len 864 errs 0
NAC 0x3D2 DUID 0xA len 864 errs 0 LDU2: rc -1 ALGID ff KID 8000 MI 00 00 00 00 00 00 00
00 00 00 00 00
NAC 0x3D2 DUID 0xA len 864 errs 8 LDU2: rc -1 ALGID 28 KID e000 MI 00 00 00 00 0d 00 00
00 11 00 00 00
NAC 0x3D2 DUID 0x5 len 864 errs 0
NAC 0x3D2 DUID 0xA len 864 errs 0 LDU2: rc -1 ALGID 88 KID e000 MI 00 00 00 00 18 00 00
00 00 00 00 00
NAC 0x3D2 DUID 0x5 len 864 errs 0
NAC 0x3D2 DUID 0xA len 864 errs 2 LDU2: rc -1 ALGID 8 KID a000 MI 00 00 00 00 0a 00 00
00 00 00 00 00
NAC 0x3D2 DUID 0x5 len 864 errs 0
NAC 0x3D2 DUID 0x5 len 864 errs 6
NAC 0x3D2 DUID 0xA len 864 errs 0 LDU2: rc -1 ALGID 4a KID e028 MI 00 00 00 00 32 00 00
00 1a 00 00 00
NAC 0x3D2 DUID 0x5 len 864 errs 0
NAC 0x3D2 DUID 0xA len 864 errs 0 LDU2: rc -1 ALGID b3 KID 8000 MI 00 00 00 00 32 00 00
00 00 00 00 00
NAC 0x3D2 DUID 0xA len 864 errs 1 LDU2: rc -1 ALGID 28 KID e000 MI 00 00 00 00 32 00 00
00 00 00 00 00
NAC 0x3D2 DUID 0x5 len 864 errs 0
NAC 0x3D2 DUID 0xA len 864 errs 0 LDU2: rc -1 ALGID fe KID c028 MI 00 00 00 00 00 00 00
00 00 00 00 00
NAC 0x3D2 DUID 0xA len 864 errs 0 LDU2: rc -1 ALGID e8 KID a000 MI 00 00 00 00 0d 00 00
00 35 00 00 00
NAC 0x3D2 DUID 0xA len 864 errs 10 LDU2: rc -1 ALGID ff KID c000 MI 00 00 00 00 28 17 17
17 32 00 00 00
NAC 0x3D2 DUID 0x5 len 864 errs 0
NAC 0x3D2 DUID 0xA len 864 errs 0 LDU2: rc -1 ALGID cb KID 8000 MI 00 00 00 00 00 00 00
00 00 00 00 00
NAC 0x3D2 DUID 0xA len 864 errs 0 LDU2: rc -1 ALGID b8 KID e058 MI 00 00 00 00 28 00 00
00 22 00 00 00
NAC 0x3D2 DUID 0x5 len 864 errs 0
NAC 0x8F4 DUID 0xA len 864 errs 7 LDU2: rc -1 ALGID ff KID 8000 MI 00 00 00 00 32 00 00
00 32 00 00 00
NAC 0x3D2 DUID 0x5 len 864 errs 2
NAC 0x3D2 DUID 0xA len 864 errs 0 LDU2: rc -1 ALGID 1f KID f028 MI 00 00 00 00 32 00 00
00 00 00 00 00
NAC 0x3D2 DUID 0xA len 864 errs 9 LDU2: rc -1 ALGID ba KID e000 MI 00 00 00 00 28 00 00
00 32 00 00 00
NAC 0x3D2 DUID 0xA len 864 errs 1 LDU2: rc -1 ALGID f8 KID e000 MI 34 00 28 00 28 00 00
00 32 00 00 00
NAC 0x3D2 DUID 0x5 len 864 errs 0
NAC 0x3D2 DUID 0xA len 864 errs 0 LDU2: rc -1 ALGID 6c KID e000 MI 00 00 00 00 38 00 00
00 32 00 00 00
NAC 0x3D2 DUID 0x5 len 864 errs 0
NAC 0x3D2 DUID 0xA len 864 errs 5 LDU2: rc -1 ALGID bc KID e000 MI 00 00 00 00 00 00 00
00 32 00 00 00
NAC 0x3D2 DUID 0x5 len 864 errs 0
NAC 0x3D2 DUID 0xA len 864 errs 0 LDU2: rc -1 ALGID ff KID 8000 MI 00 00 00 00 00 00 00
00 00 00 00 00
NAC 0x3D2 DUID 0x5 len 864 errs 0
NAC 0x3D2 DUID 0xA len 864 errs 0 LDU2: rc -1 ALGID 1c KID d00a MI 00 00 00 00 0d 00 00
00 04 00 00 00
NAC 0x3D2 DUID 0xA len 864 errs 11 LDU2: rc -1 ALGID fe KID e000 MI 00 00 00 00 2c 00 00
00 32 00 00 00
NAC 0x3D2 DUID 0x5 len 864 errs 0
NAC 0x3D2 DUID 0xA len 864 errs 0 LDU2: rc -1 ALGID f8 KID ea00 MI 00 00 00 00 38 00 00
00 32 00 00 00
NAC 0x3D2 DUID 0x5 len 864 errs 0
NAC 0x3D2 DUID 0x3 len 72 errs 0
NAC 0x3D2 DUID 0xF len 216 errs 0
NAC 0x3D2 DUID 0xF len 216 errs 0
NAC 0x3D2 DUID 0xF len 216 errs 7
NAC 0x3D2 DUID 0xF len 216 errs 0
NAC 0x3D2 DUID 0xF len 216 errs 1
NAC 0x3D2 DUID 0xF len 216 errs 0
4:06 a.m.
And never mind at all - I am an idiot and had the nominator / denominator swapped in the
resampler block. ugh!
Sorry for wasting all this space. I do have some performance issues to sort through, but
that is a good problem to have right now!
3463
days inactive
3473
days old
7 comments
2 participants
participants (2)
-
ikj1234i＠yahoo.com [op25-dev] -
lukekb＠gmail.com [op25-dev]