Simtech plugin filtering out Waveshare Raspberry Pi 4G HAT
aleksander at aleksander.es
Thu Nov 18 09:13:25 UTC 2021
> Hi Aleksander,
> (gmail WebUI, but I'll try to do the quoting in a sane way!)
It's possible, I do it every day :D
> > > Can I force the Simtech plugin to be used, or would it make no sense because of the single serial port? Should it be claimed and usable by the AT plugin instead? I'm more than happy to change stuff on this, because it has no other use at the moment.
> > >
> > You should tag the ttyS0 interface with the "ID_MM_DEVICE_PROCESS"
> > udev tag, so that MM can process the port.
> Ah, sorry. I neglected to mention that I did try this. The AT plugin didn't seem to want to claim the device, either. If it's of use I can retry with the setting.
ID_MM_DEVICE_PROCESS is the way to go here.
But now that I think about it, being a pure serial connection, you may
also need to configure ID_MM_TTY_BAUDRATE (defaults to 57600
otherwise) and/or ID_MM_TTY_FLOW_CONTROL (The value of the tag should
be either 'none', 'xon-xoff' or 'rts-cts', and must be a flow control
value supported by the device).
>> The Simtech plugin doesn't support non-USB modems, though, so you'll
>> probably end up with the generic plugin managing the modem. If you do
>> need the Simtech plugin, we could probably update it to have "vendor
>> and product string filters" as some other plugins supporting RS232
>> modems do (i.e. with MM_PLUGIN_ALLOWED_VENDOR_STRINGS).
> I haven't tried this. I don't recollect seeing it.
First we need to solve the port probing problem, the generic plugin
should claim that port. Once that's fixed, we can see if adding the
support for vendor strings in the simtech plugin makes sense.
More information about the ModemManager-devel