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!
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
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_receive... https://github.com/robotastic/smartnet-recorder/blob/3.7-P25/logging_receive... - Luke
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
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);
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?
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
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!
-
ikj1234i＠yahoo.com [op25-dev] -
lukekb＠gmail.com [op25-dev]