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

General support for the Pi-Star System
AF6VN
Posts: 821
Joined: Fri Jul 20, 2018 1:15 am

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

Post by AF6VN »

KG7PAR wrote: Sat Aug 24, 2019 6:59 pm 0xF0 vs 0xE0 (bit 4 error)
0x83 vs 0x03 (bit 7 error)
0x80 vs 0x00 (bit 7 error)

this looks suspiciously close to the right codes you provided, but not quite there.
How are you counting bits? 7..0?

While I can't explain the first pair, the others almost look like something configured for 7-bit/mark parity (or 7-bit/odd parity), rather than 8-bit/no parity.

Asynchronous serial (UART) tends to be somewhat forgiving of timing mismatches, since each byte transferred is indicated with start-bit signal, so both ends will be in agreement on the start of the byte. You've then got only 8-bit times of data before stop bits (which would look like 0 bits if a receiver were still sampling the data line).

"Serial Port Complete 2nd Ed" suggests that UART clocks traditionally run 16X the (maximum) bit rate, and the link can have up to 3% clock rate error without data corruption. It also states that data is sent LSB first. Since stop bits are "0", a receiver sampling too slowly would read the stop bit as the final (MSB). A receiver sampling too fast would tend to duplicate the next-to-last bit as the MSB. Neither situation matches your data (if it were supposed to be x80 or x83 and you received x00/x03 I have no idea... as reading the stop bit for bit 7 implies bit 7 was read as bit 6, giving x40/x43; Similarly, duplicating next to last bit, for your data, again would see a 0 bit).

The use of a 16X (or higher) internal clock means the receiver can sample multiple times within a bit time and use the most common result (book says some hardware does this), normally sampling will be done at the middle of the bit time, or 8-internal clocks in (24 clocks after start bit detected, then every 16 clocks until stop bit time). A UART still seeing a 1-bit when it expects to sample a stop-bit (0) should produce a framing error in its status register.

Assuming the sender is accurate 115200bps (ignoring the 16X internal clock difference) a 3% delta means the receiver could be running 111744 to 118656 (115200 +/- 3456) before data corruption is noticed.

--
AF6VN
Dennis L Bieber
KG7PAR
Posts: 28
Joined: Mon Aug 19, 2019 3:20 am

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

Post by KG7PAR »

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: 28
Joined: Mon Aug 19, 2019 3:20 am

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

Post by KG7PAR »

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: 28
Joined: Mon Aug 19, 2019 3:20 am

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

Post by KG7PAR »

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: 28
Joined: Mon Aug 19, 2019 3:20 am

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

Post by KG7PAR »

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: 28
Joined: Mon Aug 19, 2019 3:20 am

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

Post by KG7PAR »

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.
KG7PAR
Posts: 28
Joined: Mon Aug 19, 2019 3:20 am

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

Post by KG7PAR »

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.
KG7PAR
Posts: 28
Joined: Mon Aug 19, 2019 3:20 am

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

Post by KG7PAR »

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
KG7PAR
Posts: 28
Joined: Mon Aug 19, 2019 3:20 am

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

Post by KG7PAR »

I will take a look at this further, I found a new problem this morning when checking the PTT, I have active low COS, which is tied to the inhibit pin, looks like I need to rethink that approach as the logic is inverted but I dont see an option to toggle the inhibit logic in the dashboard.

I also noted in the cal utility that the 'e' option doesnt exist anymore.

Think I also need to request the default serial port not override the user set one as well when working outside the expert mode. easy enough to fix for me, but not ideal for a product design.
KG7PAR
Posts: 28
Joined: Mon Aug 19, 2019 3:20 am

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

Post by KG7PAR »

here is the menu option I get when I issue the help command, no "e", no shift+F

The commands are:
H/h Display help
Q/q Quit
W/w Enable/disable modem debug messages
I Toggle transmit inversion
i Toggle receive inversion
O Increase TX DC offset level
o Decrease TX DC offset level
C Increase RX DC offset level
c Decrease RX DC offset level
P/p Toggle PTT inversion
R Increase receive level
r Decrease receive level
T Increase transmit level
t Decrease transmit level
d D-Star Mode
D DMR Deviation Mode (Adjust for 2.75Khz Deviation)
L/l DMR Low Frequency Mode (80 Hz square wave)
A DMR Duplex 1031 Hz Test Pattern (TS2 CC1 ID1 TG9)
M/m DMR Simplex 1031 Hz Test Pattern (CC1 ID1 TG9)
a P25 1011 Hz Test Pattern (NAC293 ID1 TG1)
N NXDN 1031 Hz Test Pattern (RAN1 ID1 TG1)
K/k BER Test Mode (FEC) for D-Star
b BER Test Mode (FEC) for DMR Simplex (CC1)
B BER Test Mode (1031 Hz Test Pattern) for DMR Simplex (CC1 ID1 TG9)
J BER Test Mode (FEC) for YSF
j BER Test Mode (FEC) for P25
n BER Test Mode (FEC) for NXDN
S/s RSSI Mode
V/v Display version of MMDVMCal
<space> Toggle transmit
Post Reply