base station stops responding after first response to rf

Tyler V

unread,

Feb 24, 2019, 8:28:19 PM2/24/19

to PrivateEyePi

Apologies in advance if I missed the answer when searching the forum or messed something up. Playing with base station for the first time after buying it a while ago and never getting around to it. I spend my work life at a linux prompt (not a linux admin tho) but this is my first foray into these devices and I don't use my Pi all that often.

Brand new standard NOOBS install of Raspbian on a Pi 2. Followed the directions/docs on how to set up for everything, and success, got the base station to respond to HELLO ... but only once after each power cycle of the Pi.

It typically will respond once, and only after a hard power reset (shutdown -r doesn't fix it). Rarely I've seen it respond twice, and once three times, but always it goes into permanent no-response after that.
The only thing I could think of was poor power to the Pi, have dealt with that in the past, so I grabbed some python to monitor the power status/led status and it's fine, never dips below the acceptable limit. No yellow lightning bolt either. Not much plugged into the Pi, just hdmi, ethernet, and the board (sshing in from another machine so no keyboard/mouse).
I edited the rf_config.py to increase the timeout and print a few more things ... no luck no matter how long I make it wait on ser.inWaiting.

What else should I check before it would be fair to decide the base unit might be at fault? How do I know it's not the Pi? I can write python / grab other libraries and stitch things together if there's something else I can monitor to see what exactly is going on. Thinking there might be another way to query the board with "are you alive?" Or maybe HELLO is the most basic check. Also curious how to see if the Pi's handling of GPIO is still happy, or if it's something in that area. I just don't know what direction to go next to diagnose root cause. Hoping someone has some ideas. Happy to RTFM if you link me. Or maybe you can tell me if this is enough "wonky" behavior to be worth asking for support directly from the maker/seller.

Example (with unmodified rf_config.py):

pi@raspberrypi:/opt/rf_tools $ while [[ 1 = 1 ]];do sleep 5;  python rf_config.py 01 HELLO; done

sending     : a01HELLO
response is : a01HELLO----

sending     : a01HELLO
sending     : a01HELLO
sending     : a01HELLO

sending     : a01HELLO
sending     : a01HELLO
sending     : a01HELLO

sending     : a01HELLO
sending     : a01HELLO
sending     : a01HELLO

sending     : a01HELLO
sending     : a01HELLO
sending     : a01HELLO

... etc ... this will stay consistent for a long time, never works again.

from /var/log/syslog during startup (not while running the HELLO test) -- there's a pause before systemd reports it's done with startup, and when it's done pausing this is what is written immediately (then typical done-startup msgs).

Feb 24 19:03:33 raspberrypi systemd[1]: dev-serial1.device: Job dev-serial1.device/start timed out.
Feb 24 19:03:33 raspberrypi systemd[1]: Timed out waiting for device dev-serial1.device.
Feb 24 19:03:33 raspberrypi systemd[1]: Dependency failed for Configure Bluetooth Modems connected by UART.
Feb 24 19:03:33 raspberrypi systemd[1]: hciuart.service: Job hciuart.service/start failed with result 'dependency'.
Feb 24 19:03:33 raspberrypi systemd[1]: dev-serial1.device: Job dev-serial1.device/start failed with result 'timeout'.

Keep in mind it works (once) after this, this is part of the startup messages in syslog.

Bluetooth made me think ... hrm, docs said to disable bluetooth on a Pi 3 ... this is a Pi 2, but ok, why not. So I tried adding dtoverlay=pi3-disable-bt to the /boot/config.txt and it didn't help.

This is written to syslog exactly once when I run the rf_config.py script, even if it works 2 or 3 times before it stops working:

Feb 24 19:06:31 raspberrypi kernel: [  270.369065] uart-pl011 3f201000.serial: no DMA platform data

During startup it has this to say about uart-pl011, in case that means anything:

Feb 24 19:01:37 raspberrypi kernel: [    1.138291] uart-pl011 3f201000.serial: cts_event_workaround enabled
Feb 24 19:01:37 raspberrypi kernel: [    1.145908] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 87, base_baud = 0) is a PL011 rev2

Google tells me that UART1 doesn't have DMA support so probably a red herring. it's just all I can find in logs.

Thanks very much!

Tyler

Gadjet Nut

unread,

Feb 25, 2019, 7:35:48 AM2/25/19

to Tyler V, PrivateEyePi

Did you disable the login shell and enable serial port?

http://projects.privateeyepi.com/home/home-alarm-system-project/wireless-projects/configure-the-serial-port-on-rpi2-and-rpi3

Something else: check if there is another application using the serial port (like rfsensor.py) and if so kill that before running rf_config.py.

Tyler van Vierzen

unread,

Feb 25, 2019, 10:26:28 AM2/25/19

to Gadjet Nut, privat...@googlegroups.com

Thanks for the fast response! Yes I did follow that doc, and checked it / configured it again just to be sure (after I noticed it was only working once after hard boot).

Good point on the serial port, I'll check that out today, thank you!

Tyler V

unread,

Feb 25, 2019, 12:52:04 PM2/25/19

to PrivateEyePi

Nothing else ever shows up as using IRQ 87 ... some tests below (proving nothing). Despite a lack of correlation with low power events in dmesg, I just ordered a proper canakit power supply. Haven't had any luck finding mine. It's on a decent power source but you never know. I got a few more successes (before failure) out of it after disconnecting the hdmi and going totally headless.

root@raspberrypi:~# cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p7 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait splash plymouth.ignore-serial-consoles
r

# before use 
root@raspberrypi:~# stty -F /dev/ttyAMA0
speed 9600 baud; line = 0;
-brkint -imaxbel

# after being used once
root@raspberrypi:~# stty -F /dev/ttyAMA0
speed 9600 baud; line = 0;
min = 0; time = 0;
-brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

root@raspberrypi:~#  setserial -g /dev/ttyAMA0
/dev/ttyAMA0, UART: undefined, Port: 0x0000, IRQ: 87

Number of times used for port 87 (in /proc/interrupts) stays static after it 
stops working - never increments upon failed retries.

# before use - no port 87
root@raspberrypi:~# cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
...
 86:        270          0          0          0  ARMCTRL-level  88 Edge      mmc0
FIQ:              usb_fiq
IPI0:          0          0          0          0  CPU wakeup interrupts
...
Err:          0

# after successful use, listed, note description (uart-pl011) not filled in when not actively in use
root@raspberrypi:~# cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
...
 86:        270          0          0          0  ARMCTRL-level  88 Edge      mmc0
 87:          2          0          0          0  ARMCTRL-level  89 Edge
FIQ:              usb_fiq
...
Err:          0

# when actively in use and also when it has broken and is no longer incrementing uses BUT I'm still trying to send to it...
# once i kill the attempts to send to it, then the uart-pl011 goes away again, so I'd surmise the OS is seeing the attempts
root@raspberrypi:~# cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
...
 86:        276          0          0          0  ARMCTRL-level  88 Edge      mmc0
 87:         16          0          0          0  ARMCTRL-level  89 Edge      uart-pl011
FIQ:              usb_fiq
...
Err:          0

Gadjet Nut

unread,

Feb 25, 2019, 6:21:44 PM2/25/19

to Tyler V, PrivateEyePi

If you can get it working can you send us the exact model RPI and the distro you are using?

Also try running serialmon.py and see if anyessages are coming through from your sensors.

Tyler V

unread,

Feb 27, 2019, 5:58:32 PM2/27/19

to PrivateEyePi

Well, got the brand new Pi 3 B+ with a good power supply, did the standard NOOBS install of the latest stuff (download live install), ran through the docs/config again to disable serial ssh console and to turn off bluetooth. Exact same behavior. So, I have to think it's the RF base station.

To answer your question about the sensors - they can't communicate with it either, that's what originally made me realize it wasn't responding after trying 3 different coin batteries ... and sent me back to try more than once with HELLO to test, only to find out it froze after a few responses. Or maybe they can communicate with it, but it can't tell the OS/python that they are because the interface via GPIO is frozen/not responding. One way or the other, sensors don't work.

This thing was ordered Dec 2, 2017 (order: 5851) and then kicked around my home office for a while still in its plastic bag packaging / open box, so I can't guarantee some static or the like didn't find its way to it in that time. So I'm not angling for a replacement. Heck they're not that expensive. I believe if I order another https://www.jemrf.com/collections/rf-sensors/products/wireless-base-station-for-raspberry-pi?variant=21297867063356 then it will work with the water/motion/entry sensors I bought in Dec 2017? No changes?