(RPI) Changing the tty to an external device and validating functionality

General support for the Pi-Star System
KG7PAR
Posts: 24
Joined: Mon Aug 19, 2019 3:20 am

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KG7PAR » Wed Aug 28, 2019 4:13 am

This is a prototype 1 board that I am getting turned on for the time.

per this page, i could be getting errors as high as 5% due to the master crystal being at 12.288 MHz which doesnt divide down nicely. I have proper devices on order from digikey that should be here Thursday or friday that I will fly wire into the UART clock pin, hopefully that will clear this all up.

https://cache.amobbs.com/bbs_upload7821 ... 08497.html

As for the weird packets, I agree they are strange for the errors received, but the crystal is the most obvious problem since the port 1 runs perfectly at 9600 baud which is expected per that page with a 0% error rate. In my mind this is corroborated by the fact the external uart chip works perfectly with the stm device.

for connections, I now have !RST on pin 16, SWDIO on 24, and SWCLK on 26. I believe these correspond to 23/8/7 for gpio numbering. Originally these were hooked up to a mcp23017 gpio expander but that seems to be incompatible with the openocd programming so I had to move them to these pins as they were available still. the programming part works perfectly, and the chip responds when only the Tx/Rx/gnd are hooked up externally.

KG7PAR
Posts: 24
Joined: Mon Aug 19, 2019 3:20 am

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KG7PAR » Wed Aug 28, 2019 4:18 am

Thats really crazy that you are getting bit errors like that, I'm not sure what could be causing that. Is this coming right off the UART board and into the USB->UART adapter?

I2C shouldn't have any problems going that slow, I know on drone flight controllers that use STM32's, they are running i2c at 800kHz.

You have GPIO 24 (pin 18) connected to both the UART board and the RPi for IRQ right?
The errors were caught using my external uart effectively soldered into the board as a second Rx on the board in parallel with the STM.

I am still running i2c at 100k (default), but I believe I can kick it up to 400k safely with the chips on the board, but I will need to confirm all the datasheets to make sure of that. I have no current reason to assume the i2c is starved for bandwidth as the GPS is running slow (9600) and even then only dumps about 100 characters about 8 times a second. I have some ADC devices and a sound card on the bus as well, but they should not be doing much traffic either (if any right now)

KG7PAR
Posts: 24
Joined: Mon Aug 19, 2019 3:20 am

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KG7PAR » Sat Aug 31, 2019 5:06 am

Just a quick update on this topic.

I got the new crystals today and have it installed. I am now using 3.6864 MHZ which should be a perfect crystal for all uart speeds under 115200 down to 9600.

Bad news for the night is that I can no longer even load the device into the system, it just barfs when it tries to load. I have a follow-up in with the rpi admins to see if their updated code hasn't caused this unexpected behavior. I don't see where it would have, but checking just to be sure.

I have modded the board back to use the original crystal and still broken, so waiting to get their response

KG7PAR
Posts: 24
Joined: Mon Aug 19, 2019 3:20 am

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KG7PAR » Sun Sep 01, 2019 2:54 pm

I found why you are seeing the same uart potentially. Just found this is the /boot/config.txt file on the 4.1RC4 image. same chipset, just on spi instead of i2c

# D2RG UART over SPI
dtoverlay=sc16is752-spi0-ce0

KG7PAR
Posts: 24
Joined: Mon Aug 19, 2019 3:20 am

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KG7PAR » Sun Sep 01, 2019 3:29 pm

I think everything is working now, I jumped up to the 4.1RC4 so I could pull down the changes from the rpi admins and now I get this in the log monitor

Starting logging, please wait...
E: 2019-09-01 15:23:08.901 No reply from the modem for some time, resetting it
M: 2019-09-01 15:23:08.901 Closing the MMDVM
M: 2019-09-01 15:23:10.901 Opening the MMDVM
I: 2019-09-01 15:23:12.936 MMDVM protocol version: 1, description: MMDVM 20190130 (D-Star/DMR/System Fusion/P25/NXDN/POCSAG) 12.0000 MHz GitID #ff7a9fd

Second uart port is also working now as well for the GPS. Now to go back and reconfigure all the GPS stuff on this new image.

KE7FNS
Posts: 421
Joined: Wed Apr 17, 2019 11:11 pm

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KE7FNS » Tue Sep 03, 2019 8:20 am

KG7PAR wrote:
Sun Sep 01, 2019 2:54 pm
I found why you are seeing the same uart potentially. Just found this is the /boot/config.txt file on the 4.1RC4 image. same chipset, just on spi instead of i2c
Yeah, it is weird that it sets up serial ports even when the physical chip isn't even connected. shrug
KG7PAR wrote:
Sun Sep 01, 2019 3:29 pm
E: 2019-09-01 15:23:08.901 No reply from the modem for some time, resetting it
M: 2019-09-01 15:23:08.901 Closing the MMDVM
M: 2019-09-01 15:23:10.901 Opening the MMDVM
I: 2019-09-01 15:23:12.936 MMDVM protocol version: 1, description: MMDVM 20190130 (D-Star/DMR/System Fusion/P25/NXDN/POCSAG) 12.0000 MHz GitID #ff7a9fd
Its a little odd that you are seeing that message "No reply from the modem for some time, resetting it". You don't have anything connected to the ST-Link port on the hat do you?
All views, comments, posts and opinions shared are entirely my own.

KG7PAR
Posts: 24
Joined: Mon Aug 19, 2019 3:20 am

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KG7PAR » Thu Sep 05, 2019 2:53 am

I fired up a second board and checked the logs, I suspect that was something I did the blipped it. I think I might have been testing the programming function through openocd around the same time.

KE7FNS
Posts: 421
Joined: Wed Apr 17, 2019 11:11 pm

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KE7FNS » Fri Sep 06, 2019 1:22 am

Yeah, MMDVMHost gets really unhappy with my modem when I try to hook up the SWD. I haven't been able to get it to work like I thought I could, which is disappointing cause I wanted to be able to watch and see how it functioned.
All views, comments, posts and opinions shared are entirely my own.

KG7PAR
Posts: 24
Joined: Mon Aug 19, 2019 3:20 am

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KG7PAR » Mon Sep 09, 2019 2:49 am

Can you recommend some places to get started with configuring the mmdvm and the MD380 rigs to talk to each other. Been fighting this for a bit now and I cant get anything in the logs or dashboard that even looks like the radio is talking to the mmdvm controller.

I have confirmed I have audio from the rx making it into the pin of the chip atleast, but from there its all magic smoke at the moment.

here is the logs of what I have setup right now, no idea if its right or not

Code: Select all

I: 2019-09-09 02:35:56.003 MMDVM protocol version: 1, description: MMDVM 20190130 (D-Star/DMR/System Fusion/P25/NXDN/POCSAG) 12.0000 MHz GitID #ff7a9fd
I: 2019-09-09 02:35:56.023 Display Parameters
I: 2019-09-09 02:35:56.023 Type: None
W: 2019-09-09 02:35:56.023 No valid display found, disabling
I: 2019-09-09 02:35:56.023 DMR Network Parameters
I: 2019-09-09 02:35:56.023 Address: 74.91.114.19
I: 2019-09-09 02:35:56.023 Port: 62031
I: 2019-09-09 02:35:56.023 Local: random
I: 2019-09-09 02:35:56.023 Jitter: 360ms
I: 2019-09-09 02:35:56.023 Slot 1: disabled
I: 2019-09-09 02:35:56.023 Slot 2: enabled
I: 2019-09-09 02:35:56.023 Mode Hang: 20s
I: 2019-09-09 02:35:56.024 Info Parameters
I: 2019-09-09 02:35:56.024 Callsign: KG7PAR
I: 2019-09-09 02:35:56.024 RX Frequency: 146640000Hz
I: 2019-09-09 02:35:56.024 TX Frequency: 146640000Hz
I: 2019-09-09 02:35:56.024 Power: 1W
I: 2019-09-09 02:35:56.024 Latitude: 50.000000deg N
I: 2019-09-09 02:35:56.024 Longitude: -3.000000deg E
I: 2019-09-09 02:35:56.024 Height: 0m
I: 2019-09-09 02:35:56.024 Location: "Snohomish"
I: 2019-09-09 02:35:56.024 Description: "United States"
I: 2019-09-09 02:35:56.024 URL: "http://www.mw0mwz.co.uk/pi-star/"
M: 2019-09-09 02:35:56.024 DMR, Opening DMR Network
I: 2019-09-09 02:35:56.024 RSSI
I: 2019-09-09 02:35:56.024 Mapping File: /usr/local/etc/RSSI.dat
I: 2019-09-09 02:35:56.026 Loaded 14 RSSI data mapping points from /usr/local/etc/RSSI.dat
I: 2019-09-09 02:35:56.026 DMR Id Lookups
I: 2019-09-09 02:35:56.026 File: /usr/local/etc/DMRIds.dat
I: 2019-09-09 02:35:56.026 Reload: 24 hours
I: 2019-09-09 02:35:56.588 Loaded 140685 Ids to the DMR callsign lookup table
I: 2019-09-09 02:35:56.589 DMR RF Parameters
I: 2019-09-09 02:35:56.589 Id: 3132763
I: 2019-09-09 02:35:56.589 Started the DMR Id lookup reload thread
I: 2019-09-09 02:35:56.589 Color Code: 1
I: 2019-09-09 02:35:56.589 Self Only: no
I: 2019-09-09 02:35:56.589 Embedded LC Only: no
I: 2019-09-09 02:35:56.589 Dump Talker Alias Data: yes
I: 2019-09-09 02:35:56.589 Prefixes: 0
I: 2019-09-09 02:35:56.589 Call Hang: 3s
I: 2019-09-09 02:35:56.589 TX Hang: 4s
I: 2019-09-09 02:35:56.589 Mode Hang: 20s
M: 2019-09-09 02:35:56.589 MMDVMHost-20190625_Pi-Star-v4 is running
M: 2019-09-09 02:35:56.849 Mode set to Lockout
M: 2019-09-09 02:36:06.791 DMR, Logged into the master successfully

KE7FNS
Posts: 421
Joined: Wed Apr 17, 2019 11:11 pm

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KE7FNS » Mon Sep 09, 2019 8:02 am

Well, it looks good from what I can tell, there really shouldn't be any configuration needed, just match up the freq, CC, TS, and talkgroup.

I see that you are out of the satellite blocked area, so things are good there.

I think what I'd do is run MMDVMCal, and plink around with that and see if you can find the correct offset, I've read some horror stories about some people saying their chinesium ADF7021 chip was way out like we are talking khz off.


First: your radio needs a new channel programmed in it to use CC1 ID1 TG9, yes thats CC1 and ID of 1 not your DMR ID, and talkgroup 9.

you'll need to ssh in and type

Code: Select all

sudo pistar-mmdvmcal
Then you should hit 'e' and type in the frequency the MD-380 is supposed to be transmitting on. You'll need to enter ALL 9 digits, no periods or commas, 9 digits including all the extra zeros, no more and no less. Gotta love programmers that don't pad the data on entry. XD

double check that the frequency displayed on the menu is the correct one.

(You might have a problem here since its a duplex board, I know on my duplex board it was unhappy and wouldn't work until I programmed the radio to transmit like it was simplex (I'd get repeater not found or something when I tried to use it as a normal repeater, I ended up going into the VFO mode and forcing it to simplex))

then hit 'b'
REMEMBER: Your radio needs to be programmed on CC1 ID1 TG9 for this to work.

Once that is all set, you key up the radio for like 5 or 10 seconds and see if you see any responses on the screen. If not you tap SHIFT+ F a few times to move the receiving frequency up by a tiny amount and 'f' to lower the frequency a tiny amount. You tune around looking for the lowest BER reported. Once you find the best (lowest BER) you can simply hit 'h' to display the menu again so you can read the frequency that you tuned too.

You might have to go pretty far to compensate for it being picky, not sure how much is too much etc. Mine was like +200, but the paperwork recommended -475. shrug.

You might be able to take a SDR Dongle or a signal monitor (something you can tune and see a spektrum with) and use MMDVMcal to output a tone using one of the commands I forget which one it is, and then find it using the SDR dongle and see how far its off, that might give you an idea of how far it is off on transmit, it might be the same offset on RX.

'q' will exit MMDVMCal when you are done.

Once you figure out that offset you can use that difference TXOffset and RXOffset area in the Expert configuration area of MMDVMHost and you should be good to go.

Hopefully you will be able to breeze through it with those instructions, if not fire me a PM, and I'll send you my phone number and we can setup a time where I can walk you through it, it shouldn't take very long.
All views, comments, posts and opinions shared are entirely my own.

Post Reply