Conduit mLinux and LORIOT
Home › Forums › Conduit: mLinux Model › Conduit mLinux and LORIOT
- This topic has 2 replies, 3 voices, and was last updated 9 years, 6 months ago by
Jesse Gilles.
-
AuthorPosts
-
September 28, 2015 at 6:19 am #9406
Guillermo Glaria
ParticipantGood morning,
I am working with the Conduit mLinux version and I have a problem with the binary that provide me the Loriot cloud service. It is not working correctly. The issue is that when I run it, eliminating the LoRa server and the packet forwarder of Multitech first, the USB driver logs errors, and most of the frames sent by the mDot are lost. Only a few ones reach to the server in the cloud, and all others are not detected by the Conduit’s Loriot application because are lost in the USB FTDI. The Loriot’s support said me that they have tested the binary with the Conduit AEP version and it runs OK. But with the mLinux version the behaviour is erroneous. The error in the log is: mtcdt user.debug kernel: usb 1-2.2: usbfs: usb_submit_urb returned -121.
When I run the binary with strace, the trace errors are those repeating all the time:
clock_gettime(CLOCK_MONOTONIC, {315, 221587000}) = 0
ioctl(8, USBDEVFS_SUBMITURB, 0x638a0) = 0
timerfd_settime(7, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={435, 221587000}}, NULL) = 0
poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLOUT}], 3, 60000) = 1 ([{fd=8, revents=POLLOUT}])
ioctl(8, USBDEVFS_REAPURBNDELAY, 0xbeb8a984) = 0
timerfd_settime(7, 0, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
clock_gettime(CLOCK_MONOTONIC, {315, 226495000}) = 0
ioctl(8, USBDEVFS_SUBMITURB, 0x638a0) = 0
timerfd_settime(7, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={435, 226495000}}, NULL) = 0
poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLOUT}], 3, 60000) = 1 ([{fd=8, revents=POLLOUT}])
ioctl(8, USBDEVFS_REAPURBNDELAY, 0xbeb8a964) = 0
timerfd_settime(7, 0, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
clock_gettime(CLOCK_MONOTONIC, {315, 231618880}) = 0
ioctl(8, USBDEVFS_SUBMITURB, 0x64418) = 0
ioctl(8, USBDEVFS_SUBMITURB, 0x64444) = -1 EREMOTEIO (Remote I/O error)
timerfd_settime(7, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={435, 231618000}}, NULL) = 0
poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLOUT}], 3, 60000) = 1 ([{fd=8, revents=POLLOUT}])
ioctl(8, USBDEVFS_REAPURBNDELAY, 0xbeb8a92c) = 0
timerfd_settime(7, 0, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
clock_gettime(CLOCK_MONOTONIC, {315, 237913360}) = 0
ioctl(8, USBDEVFS_SUBMITURB, 0x64418) = 0
ioctl(8, USBDEVFS_SUBMITURB, 0x64444) = -1 EREMOTEIO (Remote I/O error)Any idea on how to resolve this issue?
Thank you and regards,
GilenSeptember 28, 2015 at 3:24 pm #9408Brandon Bayer
BlockedGuillermo,
I don’t have any ideas as to what is wrong. Unfortunately, we can’t support third-party software. That response from Loriot is odd, as their website states they only support mLinux.
In any case, there are a few people using Loriot in the below thread. Perhaps you can find some more help there:
http://openlora.com/forum/viewtopic.php?f=5&t=6&start=10
-Brandon
-
This reply was modified 9 years, 6 months ago by
Brandon Bayer.
-
This reply was modified 9 years, 6 months ago by
Brandon Bayer.
September 28, 2015 at 3:34 pm #9412Jesse Gilles
BlockedGuillermo,
Have you tested this after a cold boot and it still occurs? Or did this only happen after stopping the MultiTech software and then running the Loriot software with out a power cycle in between? It is possible the MTAC-LORA card needs to be reset when switching to the Loriot application and the Loriot software is not doing it.
If you haven’t already, my recommendation would be to try the following:
* Disable MultiTech packet forwarder and network server from starting on boot (see files in /etc/default)
* Power off
* Power on (network server disabled)
* Start Loriot appIf you do the above and still get errors then I would follow Brandon’s advice.
Thanks,
Jesse -
This reply was modified 9 years, 6 months ago by
-
AuthorPosts
- You must be logged in to reply to this topic.