(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 » Mon Sep 09, 2019 3:05 pm

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

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

Post by KG7PAR » Tue Sep 10, 2019 3:17 am

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

KE7FNS
Posts: 409
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 10, 2019 5:14 am

Well, crap, that isn't going to work. For some reason MMDVMCal has two different menus and it checks somewhere in the modem firmware and thats what decides which menu to display. Obviously I've only tinkered with MMDVM_HS firmwares, so thats the menu I was familiar with and suggested it, and I have no idea how MMDVMCal even works for the old MMDVM firmware, it doesn't even appear you can adjust the tuning. Maybe someone added this feature when they forked the MMDVM_HS and never bothered to add it to the MMDVM menu.... I really don't have any idea why theres two menus.

I can't think of an easy way to tune the offset without that menu but I guess you could just try putting in offsets in the expert config. I'd try like 100 or 250 at a time both above and below and see if you can stumble onto the offset it is happy with.
All views, comments, posts and opinions shared are entirely my own.

KE7FNS
Posts: 409
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 10, 2019 5:55 am

I have found where MMDVMCal is looking at the firmware response and deciding which menu to load. 8-)

I "think" I can trick it into thinking it is the MMDVM_HS firmware, which would load the other menu and give you more options. Have you managed to download the source code from N4IRS's github and get it built? If so we can make a tiny change, rebuild it, upload it to the modem and see what happens. The worst that can possibly happen is it doesn't work, and then we just either revert the change and recompile, or load the precompiled firmware that N4IRS provides and you are back to square one.

You should be able to start with these instructions and skip ahead to line 13 (the lines prior to that assume you are starting from a fresh never booted SD card.)

Code: Select all

cd /srv
https://github.com/N4IRS/MMDVM-Install/ ... /STM32-DVM
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 » Sat Sep 14, 2019 8:16 pm

I am giving the compiling a try now to see how it goes. I found a board bug where I needed to invert the inhibit pin, I thought it was active low so the chip has been inhibited. Got that fixed up now, getting lots of red spaghetti on this board now :-)

So I got most of the way through compilation, but hit an error in the sanity check point

[email protected](rw):MMDVM# make -f Makefile.CMSIS
echo "#define GITVERSION \"8a60fc1\"" > GitVersion.h
mkdir -p obj
mkdir -p bin
arm-none-eabi-g++ -MMD -mthumb -mlittle-endian -mcpu=cortex-m3 -Wall -I. -ISTM32F10X_Lib/CMSIS/Include -ISTM32F10X_Lib/CMSIS/Device/ST/STM32F1xx/Include -Isystem_stm32f1xx -DSTM32F105xC -DMADEBYMAKEFILE -DSTM32F1 -Os -flto -ffunction-sections -fdata-sections -g -nostdlib -fno-exceptions -fno-rtti -c CalDStarRX.cpp -o obj/CalDStarRX.o
In file included from CalDStarRX.cpp:20:0:
Globals.h:27:10: fatal error: stm32f1xx.h: No such file or directory
#include "stm32f1xx.h"
^~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile.CMSIS:129: obj/CalDStarRX.o] Error 1
[email protected](rw):MMDVM#

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

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

Post by KE7FNS » Sat Sep 14, 2019 8:48 pm

Heh, just happened to be online.

Yeah, looks like N4IRS only installs the libs for the STM32 F4, and your code is looking for a F1 lib.

try

Code: Select all

cd /usr/src/MMDVM

git clone https://github.com/shawnchain/STM32F10X_Lib.git
Theres also a
https://github.com/juribeparada/STM32F7XX_Lib.git But I don't think you will need it.

That should do it.
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 » Sat Sep 14, 2019 9:12 pm

okay forward progress (i think) starting to get debug messages when I key up the HT, any chance these mean anything to you? Note these are still with the original firmware

M: 2019-09-14 21:09:22.172 MMDVMHost-20190625_Pi-Star-v4 is running
M: 2019-09-14 21:09:32.388 DMR, Logged into the master successfully
M: 2019-09-14 21:09:53.633 Debug: DMRDMORX: csbk found pos/centre/threshold 1346 -118 198
M: 2019-09-14 21:09:54.737 Debug: DMRDMORX: csbk found pos/centre/threshold 479 -159 192
E: 2019-09-14 21:11:44.445 No reply from the modem for some time, resetting it
M: 2019-09-14 21:11:44.445 Closing the MMDVM
M: 2019-09-14 21:11:46.472 Opening the MMDVM
I: 2019-09-14 21:11:48.511 MMDVM protocol version: 1, description: MMDVM 20190130 (D-Star/DMR/System Fusion/P25/NXDN/POCSAG) 12.0000 MHz GitID #ff7a9fd
E: 2019-09-14 21:11:48.532 DMR, Connection to the master has timed out, retrying connection
M: 2019-09-14 21:11:48.532 DMR, Closing DMR Network
M: 2019-09-14 21:11:48.532 DMR, Opening DMR Network
M: 2019-09-14 21:11:54.655 DMR, Logged into the master successfully
M: 2019-09-14 21:13:53.871 Debug: DMRDMORX: csbk found pos/centre/threshold 1247 -135 208
M: 2019-09-14 21:13:54.974 Debug: DMRDMORX: csbk found pos/centre/threshold 375 -124 191
E: 2019-09-14 21:13:59.728 No reply from the modem for some time, resetting it
M: 2019-09-14 21:13:59.728 Closing the MMDVM
M: 2019-09-14 21:14:01.756 Opening the MMDVM
I: 2019-09-14 21:14:03.792 MMDVM protocol version: 1, description: MMDVM 20190130 (D-Star/DMR/System Fusion/P25/NXDN/POCSAG) 12.0000 MHz GitID #ff7a9fd
M: 2019-09-14 21:14:10.945 Debug: DMRDMORX: csbk found pos/centre/threshold 629 -127 172
M: 2019-09-14 21:14:12.601 Debug: DMRDMORX: csbk found pos/centre/threshold 49 -118 166

still chunking though

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

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

Post by KE7FNS » Sat Sep 14, 2019 9:22 pm

Not really, I'm sorry.

I wonder if this needs to be done.
https://github.com/g4klx/MMDVM/wiki/MMDVM-Calibration

I'm heading off to watch a ballgame for a few hours and won't be back until late tonight.

I'll PM 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 » Sat Sep 14, 2019 9:26 pm

I found a reference for those messages, but the results are a bit odd for my board

https://github.com/N4IRS/MMDVM-Install/ ... -threshold
The pos number is an indication of the detected sync word position. Ideally it should remain constant. If it increments or decrements it is a sign of timing drift between the Arduino and the radio. The faster it changes the worse the timing error. That is what the external high precision oscillator fixes. With a precision oscillator the pos number only changes very slowly, maybe one or two over a three minute transmission. BER will rise slightly around pos changes because the sampling point of the data is not in an ideal position at these times. A steady sample position gives more consistent decodes.
so from my results this implies the crystal (oscillator in my case) is very unstable, but its supposed to be 30ppm unless the assembler substituted in a low precision substitute. I think I have a frequency counter around here somewhere, might have to check the signal out to be sure

Enjoy your game!

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 Sep 21, 2019 10:16 pm

back at it again, no idea why those readings are so inconsistant, I hooked up a frequency counter and the crystals are very stable within a few hertz over a period of time.

I have sent one board off to a friend who is far more digital setup knowledgeable to look at as well.

I am on to another challenge in parallel.

I am blending with svxlink for analog repeater functionality and the known functional code is having a problem. The gpio are being exported okay, but they are not getting configured. We are suspecting it may be because of the RO file system. Do you know how to disable the disk from being forced to RO right off? I suspect a few seconds delay might be enough to clear it up, but hoping to disable it completely until I can confirm that really is the fix. I can log in via ssh and configure them with sudo, but that of course won't be acceptable for a real install. When I check the owners, they are owned by root, not svxlink like they are supposed to be is the other clue.

any insight is appreciated.

Post Reply