GrovePi+ on Pi 4, can not detect LoRa radio module

[travis.james.rich]

I am trying to connect a Grove Wio-E5 to the GrovePI+, but it is not detecting it plugged in. When I run ls /dev/tty* the list doesn’t change whether it is plugged in or not. Any ideas? Thanks. Here is my log for troubleshooting.

Check space left

Filesystem Size Used Avail Use% Mounted on
/dev/root 59G 3.6G 53G 7% /
devtmpfs 3.7G 0 3.7G 0% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 3.9G 8.6M 3.9G 1% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/mmcblk0p1 253M 49M 204M 20% /boot
tmpfs 790M 8.0K 790M 1% /run/user/1000

Check for dependencies

python 2.7.16-1 install ok installed
python-pip 18.1-5+rpt1 install ok installed
git 1:2.20.1-2+deb10u8 install ok installed
libi2c-dev 4.1-1 install ok installed
python-serial 3.4-4 install ok installed
python-rpi.gpio 0.7.0-0.1~bpo10+4 install ok installed
i2c-tools 4.1-1 install ok installed
python-smbus 4.1-1 install ok installed
scratch 1.4.0.6~dfsg1-6 install ok installed

I2C still in blacklist
SPI still in blacklist

Check for addition in /modules

I2C-dev already there
i2c-bcm2708 already there
spi-dev already there

Hardware revision

RPI4 Pi 4 Model B 8G v1.5

Check the /dev folder

i2c-1
ttyAMA0

USB device status

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M
Raspbian for Robots Version

cat: /home/pi/di_update/Raspbian_For_Robots/Version: No such file or directory

Hostname

raspberrypi

Checking for Atmega chip

avrdude: Version 5.10, compiled on Jun 18 2012 at 12:38:29
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch

     System wide configuration file is "/etc/avrdude.conf"
     User configuration file is "/root/.avrduderc"
     User configuration file does not exist or is not a regular file, skipping

     Using Port                    : unknown
     Using Programmer              : gpio
     AVR Part                      : ATMEGA328P
     Chip Erase delay              : 9000 us
     PAGEL                         : PD7
     BS2                           : PC2
     RESET disposition             : dedicated
     RETRY pulse                   : SCK
     serial program mode           : yes
     parallel program mode         : yes
     Timeout                       : 200
     StabDelay                     : 100
     CmdexeDelay                   : 25
     SyncLoops                     : 32
     ByteDelay                     : 0
     PollIndex                     : 3
     PollValue                     : 0x53
     Memory Detail                 :

                              Block Poll               Page                       Polled
       Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
       ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
       eeprom        65     5     4    0 no       1024    4      0  3600  3600 0xff 0xff
       flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
       lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
       hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
       efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
       lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
       calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
       signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

     Programmer Type : GPIO
     Description     : Use sysfs interface to bitbang GPIO lines

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DA
avrdude: safemode: efuse reads as 5

avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DA
avrdude: safemode: efuse reads as 5
avrdude: safemode: Fuses OK

avrdude done. Thank you.

Checking I2C bus for devices

Checking I2C bus 0

NOTE: it is normal for this one to fail
Error: Could not open file /dev/i2c-0' or /dev/i2c/0’: No such file or directory

Checking I2C bus 1

 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00: – 04 – – – – – – – – – – –
10: – – – – – – – – – – – – – – – –
20: – – – – – – – – – – – – – – – –
30: – – – – – – – – – – – – – – – –
40: – – – – – – – – – – – – 4c – – –
50: – – – – – – – – – – – – – – – –
60: – – – – – – – – – – – – – – – –
70: – – – – – – – –

Checking for firmware version

GrovePi has firmware version: 1.4.0

[cyclicalobsessive]

@travis.james.rich

I am trying to connect a Grove Wio-E5 to the GrovePI+, but it is not detecting it plugged in. When I run ls /dev/tty* the list doesn’t change

I wouldn’t expect it will.

You need to provide more info:

• Are you trying to connect the Wio-E5 to the GrovePi+ serial port or the RPISER port?
• Give a link to the specific Grove Wio-E5 board you are using
• (does the connection reverse the tx/rx from the GrovePi+ to the UART plug of the Wio-E5 board?)
• What baud rate are you setting?
• What OS are you running:

cat /etc/os-release

• What kernel:

uname -a

Serial interfaces do not “appear” when a serial device is connected, and disappear when disconnected.

What does ls /dev/serial* return? (/dev/serial1 ?)

So if you connected to the RPISER port, and import serial in your python, this is the gist of talking across the serial port (the concept - not usable code):

         import serial

         #Open the raspberry serial port
         ser = serial.Serial('/dev/serial1', 9600, timeout = 1)	#Open the serial port at 9600 baud

        #init serial
        ser.flush()

        cmd_xyz = "AT\r\n"  # nonsense example command
    

        try:
            ser.write(cmd_xyz)
            inp = ser.read(7)   # maybe "+AT: OK"  I don't know anything about the Wio-5
            // do something 

        except IOError:
            return [-1,-1]

Actually, you will need to ferret out all the Wio-5 interface from their C language app-note

• sending, receiving, and parsing the AT commands

[travis.james.rich]

@cyclicalobsessive

GrovePi+ serial port

Sorry, I had to to attend to medical matters all day.

Are you trying to connect the Wio-E5 to the GrovePi+ serial port or the RPISER port? 

I am using the RPISER port.

Give a link to the specific Grove Wio-E5 board you are using

I am using this board right here.
(does the connection reverse the tx/rx from the GrovePi+ to the UART plug of the Wio-E5 board?)
Unless I am very wrong, no no it does not,

What baud rate are you setting?

It should be 115200 bps
What OS are you running:
Raspbian GNU/Linux 10 (buster)
Kernal :Linux raspberrypi 5.10.103
/dev/serial* returns /dev/serial0 /dev/serial1

Thank you!

[cyclicalobsessive]

@travis.james.rich

I am using this board right here.
(does the connection reverse the tx/rx from the GrovePi+ to the UART plug of the Wio-E5 board?)
Unless I am very wrong, no no it does not,

From the schematics at least, it does look proper to me that the Grove cable that came with the Wio-5 board does not need to be altered - straight across should be good:
RPISER pin 1 is RX <–> Wio-5 Pin 1 is TX
RPISER pin 2 is TX <–> Wio-5 Pin 2 is RX
Pin3 is Vcc on both
Pin4 is Gnd on both

Grove-Wio-5:

GrovePi+:

[jimrh]

I haven’t looked at this closely, but I suspect you might have a logic level problem based on what I see here.

The Grove boards use +5v logic for the outputs and the Atmel, (and the associated boards), are +3v devices.

Be careful!  I have fried low-voltage logic boards by connecting them to a higher voltage device.

One thing you can try is connecting the device to a serial terminal interface, (through appropriate level shifters - USB <=> 3v serial devices exist - and sending standard “AT” modem commands to it and check the responses.

This device appears to have a custom firmware installed, (?!!), that (supposedly) supports “AT” modem commands.  Unfortunately, many modem manufacturers have (ahem!) “extended” the command set to meet specific features/requirements, so this command set is not standardized for any commands beyond the standard Hayes modem commands.

In many cases “AT?” should give you a list of accepted commands.  Unfortunately, as mentioned in another thread, Seeed Studios tends to interpret standards rather more liberally than most expect, so. . . .

You may wish to download the standard Hayes command set list, or there’s this one I found at Sparkfun. (which is a good source, they mean what they say, and their documentation is superb.)

https://www.sparkfun.com/datasheets/Cellular%20Modules/AT_Commands_Reference_Guide_r0.pdf

Let us know what happens.

[jimrh]

Here are some other good links:

Wikibooks Serial Programming/Modems and AT Commands
https://en.wikibooks.org/wiki/Serial_Programming/Modems_and_AT_Commands

Wikipedia’s article: Hayes AT command set
https://en.wikipedia.org/wiki/Hayes_AT_command_set

As an aside, the Wikipedia article on the SupraFAXModem 14400, has a particularly interesting paragraph:

The SupraFAXModem was by no means a perfect product. Continued high-speed use caused the driver chipset to heat up, and as the case lacked any airflow, the modems would eventually get hot enough to lose the ability to connect and start dropping calls. Another minor issue was that the status display codes in the alphanumeric display rotated through several different indications, and important information like CD would only be displayed every few seconds. Both of these issues make them unsuitable for “host side” use on a bulletin board system or Internet service provider, but on the client end these issues were simply not important.

I had a cheaper version of their 28.8 modem (in a plastic case), and it did get hot. I solved that problem by adding a heat-sink, cutting a hole in the top and mounting a 12v case fan on the top blowing air across the hot components.  It ran The New Nest BBS (an 8-bit Atari BBS) for years before the BBS was eventually decommissioned.