Need advice for the driver development of a Ublox GSM/GPRS modem

Development
#1

Hi,

I have a small SAMD21 device with a Ublox G350 modem on it. Basically this device was designed to measure the water level with pressure sensors. One at the bottom under water and one in the open air. The water level is the difference in pressure.

My goal is to send sensor data, once a day, via the modem to a MQTT broker (or maybe something else). I have the firmware written for Arduino, but I want to try and redo it all with RIOT-OS. There is an at driver that I want to use to control the modem. So far I can open a TCP socket and send data. UDP shouldn’t be hard either. It’s all very much work-in-progress and still very basic.

Can anyone give me a piece of advise how to continue? Should I be looking at netdev? If so, how do I interface to it? Are there similar devices/drivers?

Any hint is welcome.

#2

Hey Kees,

On Tue, Sep 27, 2022 at 06:03:21PM +0000, Kees Bakker via RIOT wrote:

Can anyone give me a piece of advise how to continue? Should I be looking at netdev? If so, how do I interface to it? Are there similar devices/drivers?

about two years ago I was facing a similar issue for the SODAQ SARA board [1]. In the end, I used the AT driver [2] and put all the protocol logic into the application. This was certainly the dirtiest possible solution, but I was under quite some time pressure back then and in the end it was working somehow.

I remember that @leandrolanzieri was working on cleaner solution [3] but don’t know if this effort was continued somehow. Anyway, I think providing a netapi capable AT modem driver would be my preferred solution that could be useful for many people.

Since most modems provide TCP/IP implementations up to the application layer, I’m not sure whether a netdev driver would be the right place here. Maybe @miri64 has an opinion on this topic as well.

Cheers Oleg

[1] Overview - SODAQ Support pages [2] AT (Hayes) command set library [3] https://forum.riot-os.org/t/help-with-sodaq-sara-sff-needed

– panic(“Attempted to kill the idle task!”); linux-2.2.16/kernel/exit.c

#3

I also summon @jia200x since a lot of stuff happened in gnrc_netif to the point, that I am not sure, if “providing a netapi capable AT modem driver” is sufficient still. It might be that by now netdev is required, but there also happened a lot that should make things easier.

Another netdev device that also uses AT commands is the xbee driver, maybe you could use that as an example?

#4

Great. Thanks both of you.

I’ll first start looking at xbee. If I get stuck I’ll ring the bell again.

#5

Hi Kees,

in an ideal world you would send data through the sock API and the OS would route it through the network interface to the modem. We are not (yet) there, but you can get similar results by implementing a GNRC Netif interface for the modem (similar to xbee, as Martine suggested). This can be done be implementing the gnrc_netif_ops_t interface (e.g 1)

You can then transmit/receive using netapi/netreg. You would just need to implement a set of NETOPTs in order to configure the modem (maybe even define more NETOPTs if needed). For your usecase you could even think of modelling the interface as a “non-IP payload on top of TCP/IP modem”, which means you could transmit data almost out of the box (e.g txtsnd).

Cheers, José

On 22/09/27 06:03PM, Kees Bakker via RIOT wrote:

Hi,

I have a small SAMD21 device with a Ublox G350 modem on it. Basically this device was designed to measure the water level with pressure sensors. One at the bottom under water and one in the open air. The water level is the difference in pressure.

My goal is to send sensor data, once a day, via the modem to a MQTT broker (or maybe something else). I have the firmware written for Arduino, but I want to try and redo it all with RIOT-OS. There is an at driver that I want to use to control the modem. So far I can open a TCP socket and send data. UDP shouldn’t be hard either. It’s all very much work-in-progress and still very basic.

Can anyone give me a piece of advise how to continue? Should I be looking at netdev? If so, how do I interface to it? Are there similar devices/drivers?

Any hint is welcome.

Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

#6

I’m going to put it on hold for now. There is simply not enough documentation to go much further. (That’s not a complaint. Just an observation.)

#7

Still, anything we can do to improve the documentation here?

#8

Maybe what I need is something like a dummy, skeleton driver. I could then start with task-05 of the tutorial and work my way down. Or is this a stupid idea?

#9

@aabedie is that maybe that riotgen could provide?

#10

Yes definitely. See also the Driver development guidelines. The “Helper tools” section explains how to use it to generate the driver skeleton.

#11

Thanks for riotgen. I’ve submitted a few minor issues. I’ve generated a bunch of files.

Next, a few questions

  1. is the “auto init” method still relevant? Do I need a init_my_driver.c in /sys/auto_init ? If not, how/where is the device created? I can do the setup in my application program.
  2. how/when is driver_setup being called? Is it just the setup of the driver structure? And maybe register a netdev?
  3. how/when is driver_init being called?
  4. what driver is a good example to be looking at? (I’ve looked at the xbee driver, but I’m not sure if it isn’t a bit old, as in: we do it different these days)