Problems with slice of radio using bash


#1

Hi all. I recently bought two slice of radio’s to go with 2 pi zero (1.3) and the new cameras.
I can talk between the two using minicom (to be precise minicom -b 9600 -o -D /dev/ttyAMA0
This is just fine. The problem is doing somthing more usefull in bash or sh
I have a program loop of the form (pseudo-code)

while (running)
do
if [ some control code set]
echo “some message” >/dev/ttyAMA0
fi
if [ someother control code set]
echo “some other message” >/dev/ttyAMA0
fi
if [ yet another code is set]
echo “send another message” >/dev/ttyAMA0
#get response
read f
… do something with $f
fi
… more code
done </dev/ttyAMA0

if I run minicom and quit with Ctrl-A q (leaving without resetting modem)
then run my script, it behaves as I expect, everything works.
however, If I leave minicom with Ctl-A x then nothing works, I get errors about creating device /dev/ttyAMA0 and I have to Ctrl-C and get a message (regarding the </dev/ttyAMA0 ) about not being able to open the device.
I would like to programatically do whatever minicom does to get the modem going and leave it in a working state for my script. I should mention I am running the script as root, so there should be no permissions problems, Does anyone have any ideas? thanks


#2

well, I found a solution, so for anyone else looking, this method worked.
run minicom -b 9600 -o -D /dev/ttyAMA0
test comms are working, then quit with Ctrl-A q [enter]
this leaves the port configured. now run
stty -F /dev/ttyAMA0 -g >config.txt
this saves the current port configuration.
and include at the beginning of your script,
stty -F /dev/ttyAMA0 `cat config.txt`
or alternatively, just paste the actual text of config.txt in after the stty -F /dev/ttyAMA0 part
now the port is properly configured and sending and receiving works.
Note in my example, I am receiving data sent with newlines. If your data does not have newlines, you will have to modify the read command adding extra parameters for the number of characters expected, and time-out. In fact it is good to have a time-out specified with the read command anyway, just in case the reply packet gets lost and the script gets stuck waiting for a reply.:-)