Page 3 of 3

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

Posted: Sat Sep 14, 2019 8:16 pm
by KG7PAR
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

root@pi-star(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
root@pi-star(rw):MMDVM#

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

Posted: Sat Sep 14, 2019 9:12 pm
by KG7PAR
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

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

Posted: Sat Sep 14, 2019 9:26 pm
by KG7PAR
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!

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

Posted: Sat Sep 21, 2019 10:16 pm
by KG7PAR
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.

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

Posted: Sun Sep 22, 2019 3:06 am
by KG7PAR
Wow, I now understand why I couldn't get it to come out of RO mode. I also found /boot/cmdline.txt also has it in there. I will tackle this tomorrow and see how it goes.

I am going to push up an image to my website soon that has my version of mmdvm (RC4 with trunk BUSTER OS) and also svxlink installed and configured for the board. I will share the path if you are interested.

Svxlink is an incredibly powerful analog repeater controller software package. It has been around for like 15 years, and has a large audience around the world. There is no support for digital integration, but the first board I mailed out is to one of the key developers to tinker with so who knows. I am planning just to run pi-star and svxlink in parallel, with analog set to be priority over the digital. I might make that programmable later, but for now it is done with analog signaling (Squelch drives the inhibit bin on the mmdvm).

I am hopeful that I will only need it to be RW for about the first minute or so, so some of the watchdog and misc scripts may be skipable.