Using RPi to capture received talkgroups log

[rustyhodge]

Hooked a P25rx to a Rpi and can see the device the tsunami of data coming from it.

Doing a

cat /dev/ttyACM0

will show my a LOT of data coming from the device, but I'm not sure what I need to send to it to get it in a mode where it is only returning the received talkgroups (ideally just the unencrypted ones it's receiving).

ignoring talkgroup 818 due to enc or skip
TDMA Phase II sync, freq: 857.237500, rssi: -72 dBm, TGroup: 804, Desc: SFPD A1, erate: 0.001
ignoring talkgroup 814 due to enc or skip
rssi: -73 tsbk_ps 52 sa 1 ue 1 wacn_id 0xbee00 sys_id 0x2bb nac 0x2b1 rf_id 1 site_id 21 tgzone 1 freq 851.250000 $

When I see lines like this, does it mean that it's not encrypted and not ignoring it?

P25_PII: SRC_RID: 316   GRP 816 $

What all should I be looking for, and what can I ignore?
And how do I get the audio not to be sent over the USB, just the log info?

 

[FreqNout]

While waiting for Todd to respond…You are seeing the raw usb serial data text. I do not believe the current firmware supports what you are wanting to do on the serial port. A future API being discussed in other threads may allow for custom output on the serial port. There are logging options in btconfig.

 

[btt]

The first example is what shows up when the talk group is skipped due to "skip" or "encryption". The reason it switches to the P2 channel is that it doesn't know that it is encrypted until it starts to decode on the traffic channel. The second example output shown is the RID / Talkgroup. That would be a good way to get the talk group information for now. This is going to change. @rustyhodge, if you would like, I can send you the demonstration app for the Wio terminal. That would show you how to enable a binary stream and how to parse it in 'C' if that would help. The other thing I could do is to add a command to enable a different type of output for you for your application.

 

[rustyhodge]

I can send you the demonstration app for the Wio terminal. That would show you how to enable a binary stream and how to parse it in 'C' if that would help.

That would be great.
Thanks!

 

[rustyhodge]

Forgive my my C ignorance, and maybe I'm going about this the wrong way.

In this instance:

      strcpy(cmd_buf, "logging -999\r\n\0");  //disable scrolling text output (console)
      AcmSerial.SndData( (int) strlen((char *)cmd_buf), (uint8_t *) cmd_buf );

Is it sending to the serial connection "logging -999" followed by a return and an newline and a null? Or is the \0 how the string gets terminated?

And this:

    uint16_t rcvd=64;
    memset(buf,0x00,sizeof(buf));
    AcmSerial.RcvData(&rcvd, (uint8_t *)buf);

    int i;
    if( rcvd>0) { 
      for(i=0;i<rcvd;i++) {
        process_usb_rx(buf[i]);
      }
    }

Is that grabbing 64 bytes of data at a time from the serial to process? And process_usb_rx is looking at it one byte at a time?

Is there a terminator for data coming over serial? Or are the voice blocks binary so I can't look for a terminator character?

I guess I'm really asking for advice on is how to parse that serial stream. How do I identify the start and end of voice or voice blocks? I can't figure out what's going on in process_usb_rx and I really only want the info from the sysinfo block.

Thanks and sorry to be such a pain.

 

[goldmyne99]

I guess I'm really asking for advice on is how to parse that serial stream.

Sorry to jump in. I'm sure Todd will answer the C program details.

If you send me a direct message. I may have some code examples that could get you started.

I am not a real programmer, but have had success with parsing the data for multiple projects.

 

[btt]

Forgive my my C ignorance, and maybe I'm going about this the wrong way.

In this instance:

      strcpy(cmd_buf, "logging -999\r\n\0");  //disable scrolling text output (console)
      AcmSerial.SndData( (int) strlen((char *)cmd_buf), (uint8_t *) cmd_buf );

Is it sending to the serial connection "logging -999" followed by a return and an newline and a null? Or is the \0 how the string gets terminated?

And this:

    uint16_t rcvd=64;
    memset(buf,0x00,sizeof(buf));
    AcmSerial.RcvData(&rcvd, (uint8_t *)buf);

    int i;
    if( rcvd>0) {
      for(i=0;i<rcvd;i++) {
        process_usb_rx(buf[i]);
      }
    }

Is that grabbing 64 bytes of data at a time from the serial to process? And process_usb_rx is looking at it one byte at a time?

Is there a terminator for data coming over serial? Or are the voice blocks binary so I can't look for a terminator character?

I guess I'm really asking for advice on is how to parse that serial stream. How do I identify the start and end of voice or voice blocks? I can't figure out what's going on in process_usb_rx and I really only want the info from the sysinfo block.

Thanks and sorry to be such a pain.

Hi Rusty, Yes to the first question regarding linefeed. The \0 null is not necessary since the strcpy() function does that, but it doesn't hurt anything. By sending the command string 'logging -999\r\n', that effectively disables logging output. You are correct on the second part as well. It is grabbing 64 byte blocks and processing them one byte at a time. The voice blocks, and sysinfo blocks each start with a unique 32-bit (4 bytes) sync word at the beginning. This is the switch/case section where you see it looking for those unique sync word sequences. The 0xb2517015 is the sequence for the beginning of a sysinfo block. In order to receive the sysinfo blocks, the command 'en_display 1\r\n' command must have been sent at the init() (along with the logging -999). Feel free to email.

 

[rustyhodge]

I realize one of the things I was doing wrong: On A Rpi to write to a serial port you need to be a member of the "dialout" group. You can do this by

sudo usermod -a -G  dialout pi

(the last part is the user ID you're running under).
This is why it wasn't responding to my init commands! Doh!