Unable to communicate with RFD900+

cowherdboy commented 8 years ago

Hello,

I just started testing with the RFD900+ modem. However, I am unable to communicate with it via minicom. I typed +++ and AT1 but there was no response. I have attached the flash900.log file. How can I find out if the device has been detected?

flash900.txt

gardners commented 8 years ago

Hello,

What serial speed are you running in minicom? Have you disabled hardware flow control? Do you see any output from the modem in minicom? What version of flash900 are you running? (It received a substantial update last week).

Paul.

On Tue, Jun 21, 2016 at 7:45 PM, cowherdboy notifications@github.com wrote:

Hello,

I just started testing with the RFD900+ modem. However, I am unable to communicate with it via minicom. I typed +++ and AT1 but there was no response. I have attached the flash900.log file. How can I find out if the device has been detected?

flash900.txt https://github.com/servalproject/mesh-extender-builder/files/325289/flash900.txt

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8, or mute the thread https://github.com/notifications/unsubscribe/AAonT6fh-Yj3kM4BeAU-OEKVO0NMjGD4ks5qN7msgaJpZM4I6kh6 .

cowherdboy commented 8 years ago

I am using 57600 baud rate. HW Flow Control is disabled. I have got it working on Minicom after reflashing the firmware. I first tried with the MR3020 and for some reason the firmware on the RFD900+ got corrupted (the LED turned red). We had to reflash the RFD900+'s firmware to get a green LED. I have pulled the latest flash900 this morning. The LED is still turning red and I have got a new error. I have attached the log file. flash900.txt

gardners commented 8 years ago

Hello,

Hmm.. So it gets it into the bootloader okay, but for some reason the flashing process fails to finish. It should say stuff after saying "using 24-bit addressing with this board". Was there any more output? Did flash900 crash?

Paul.

On Mon, Jun 27, 2016 at 5:42 PM, cowherdboy notifications@github.com wrote:

I am using 57600 baud rate. HW Flow Control is disabled. I have got it working on Minicom after reflashing the firmware. I first tried with the MR3020 and for some reason the firmware on the RFD900+ got corrupted (the LED turned red). We had to reflash the RFD900+'s firmware to get a green LED. I have pulled the latest flash900 this morning. The LED is still turning red and I have got a new error. I have attached the log file. flash900.txt https://github.com/servalproject/mesh-extender-builder/files/334342/flash900.txt

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8#issuecomment-228680443, or mute the thread https://github.com/notifications/unsubscribe/AAonTxL6PMfdTSjTTFes-fnHVdCVi1-wks5qP4XTgaJpZM4I6kh6 .

cowherdboy commented 8 years ago

Hello Paul,

It stopped at 24-bit addressing ... I do not see this file in the serval directory: rfd900-82-91.ihx Where is it supposed to be located?

cowherdboy commented 8 years ago

I copied the firmware from the build directory to the /serval directory on the USB drive and the radio flashing is ok now. But I am unable to see peers over the UHF. I have attached my log file (shall I raise a separate ticket?). flash900.txt

gardners commented 8 years ago

Hello,

Does minicom show incoming characters on the radio?

If you have two radios, you can test that they are working properly, by typing any old stuff to one in minicom, and then typing !! to tell the firmware to send this as a packet. It should then appear as output from the other radio.

Paul.

On Tue, Jun 28, 2016 at 1:15 PM, cowherdboy notifications@github.com wrote:

I copied the firmware from the build directory to the /serval directory on the USB drive and the radio flashing is ok now. But I am unable to see peers over the UHF. I have attached my log file (shall I raise a separate ticket?). flash900.txt https://github.com/servalproject/mesh-extender-builder/files/336248/flash900.txt

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8#issuecomment-228940649, or mute the thread https://github.com/notifications/unsubscribe/AAonT_jGNdj-MhgHG3ZG_7dnmEKQAQguks5qQJjPgaJpZM4I6kh6 .

cowherdboy commented 8 years ago

Hi Paul,

Yes, we do see characters on the minicom console as shown in the attached image. However, nothing appears on the 2nd radio when I typed test !!. minicom

gardners commented 8 years ago

Hello,

And you can do +++ on each radio to get into AT command mode ok?

Paul

On Tue, Jun 28, 2016 at 4:02 PM, cowherdboy notifications@github.com wrote:

Hi Paul,

Yes, we do see characters on the minicom console as shown in the attached image. However, nothing appears on the 2nd radio when I typed test !!. [image: minicom] https://cloud.githubusercontent.com/assets/6798969/16405772/bce63ee4-3d3c-11e6-8579-7889c4279633.jpg

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8#issuecomment-228960617, or mute the thread https://github.com/notifications/unsubscribe/AAonTzSIPDkT7FM1MMeLhpVArk35fc5aks5qQL_4gaJpZM4I6kh6 .

cowherdboy commented 8 years ago

No. I typed +++ but I am unable to get to AT command mode.

gardners commented 8 years ago

Hello,

Try changing the modem speed in minicom. It should be 230400, but if that doesn't work, try 115200 or 57600.

Paul.

On Wed, Jun 29, 2016 at 10:28 AM, cowherdboy notifications@github.com wrote:

No. I typed +++ but I am unable to get to AT command mode.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8#issuecomment-229227841, or mute the thread https://github.com/notifications/unsubscribe/AAonT7vq5qKfS6v6_sTMNeDUcqN-qDgKks5qQcMugaJpZM4I6kh6 .

cowherdboy commented 8 years ago

The default setting was at 57600. I tried 230400, 115200 and reverted back to 57600 with the same results, i.e. no access to AT command mode.

gardners commented 8 years ago

The RFD900 radios +++ detection can fail in unusual situations if you don't leave at least 1.5 seconds of silence before and after the +++, so it would be good to check that. Otherwise, do screen grabs of the stuff coming out of the radio at each of those serial speeds. We can probably get a better idea of which baud rate it thinks it is set at from the look of the characters. Even better would be for you to use minicom's capture to log file function, and create a log file for each speed.

Finally, is the radio's red light on, or is the green on one and blinking or solid? If red, it is still stuck in the boot loader, and will not respond to +++.

Paul.

On Wed, Jun 29, 2016 at 11:56 AM, cowherdboy notifications@github.com wrote:

The default setting was at 57600. I tried 230400, 115200 and reverted back to 57600 with the same results, i.e. no access to AT command mode.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8#issuecomment-229239773, or mute the thread https://github.com/notifications/unsubscribe/AAonT7zdP0lk0j_W7fhsg_YTDRM6Sf0wks5qQdfVgaJpZM4I6kh6 .

cowherdboy commented 8 years ago

Here are our observations on the LED state:

57600 – blinking green for both 115200 – blinking green for both 230400 – blinking green and blinking red

I have attached the minicom log files and screen capture. The file names indicate the baud rates (the character outputs for 57600 and 115200 are the same) 57600.txt 115200.txt 230400.txt 115200_57600 230400

cowherdboy commented 8 years ago

The top figure has baud rates of 57600 and 115200. The bottom figure is at 230400.

gardners commented 8 years ago

So, the red flashing is when the radio is sending a packet, and the blinking green says it hasn't received any packets for at least 3 seconds. Do persist trying +++, as it should work, as it seems clearly to be at 230400 based on the output, and your ability to send packets. Do you have hardware flow control turned off in minicom, as that would stop the radio receiving the +++ from you?

Anyway, it looks like it should now work with lbard fine. Is that not the case? You can try adding the "radio" keyword to the end of the lbard command line to see what it thinks it is hearing from the radio.

Paul.

On Wed, Jun 29, 2016 at 5:38 PM, cowherdboy notifications@github.com wrote:

The top figure has baud rates of 57600 and 115200. The bottom figure is at 230400.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8#issuecomment-229286214, or mute the thread https://github.com/notifications/unsubscribe/AAonT2qKziQeyZA_ZsZ_Uuwo8EHUNHm9ks5qQif9gaJpZM4I6kh6 .

cowherdboy commented 8 years ago

I am still unable to get +++ to work. Please see if my minicom configuration is correct minicom

I waited 2 seconds, typed +++, and waited for more than 2 seconds but there were no OK received.

I am still unable to see the peer across the UHF link (if there is one). This is the lbard command that is running when I do a ps: /serval/lbard 127.0.0.1:4110 lbard:lbard 8711C2E38EF95D4785C37243FBB904C8BE43C4BCF795EE07A4DA57517A5CA245 /dev/ttyATH0 rebootwhenstuck timeslave udptime logrejects meshmsonly

When I ran the command with radio I got the following: /serval/lbard 127.0.0.1:4110 lbard:lbard 8711C2E38EF95D4785C37243FBB904C8BE43C4BCF795EE07A4DA57517A5CA245 /dev/ttyATH0 radio Version 20160616.0320.1 Serial port settings before tcsetaddr: c=000018b3, i=00000000, o=00000000, l=00000000 Serial port settings attempting ot be set: c=000018b3, i=00000000, o=00000000, l=00000000 Serial port settings after tcsetaddr: c=000018b3, i=00000000, o=00000000, l=00000000 Serial port open as fd 4 My SID prefix is 8711C2E38EF9

Inserted 2BD64BF074A8B0250C72DA7446D580F4D69980C3B13587EAC932E63C256AFF12/1463371086659 into the tree: key=528215 (this is bundle #0, now total of 1 bundles, 0 ignored) Inserted 6A7D848F999FFC089062AABF8C8820822F8218A5C402D2E0CFB38177C68EEAD8/9 into the tree: key=FB10E2 (this is bundle #1, now total of 2 bundles, 0 ignored) Inserted 75C8320B2F046E363E5A453902DAE0FBC20002732FD70E492B0C0D073538904E/33 into the tree: key=B2F604 (this is bundle #2, now total of 3 bundles, 0 ignored) Inserted ABCB428560FEC2CCC6EFB36B15F4D2C2E768533A5A071C15457F0E76B089BDD1/9 into the tree: key=F127E6 (this is bundle #3, now total of 4 bundles, 0 ignored) Inserted 2149FC59636BAED06E7361AC8629CEC36E77054683D3C9671BA46A683805C558/52 into the tree: key=AFDF68 (this is bundle #4, now total of 5 bundles, 0 ignored) Inserted F453005BA71C2B71FB549D6F3ECCADB0F0BA4FA2E729A9EE85A6D6DEF097F75F/13 into the tree: key=603DC9 (this is bundle #5, now total of 6 bundles, 0 ignored) Inserted 82C1FF7E0B585D39FF7BA0E0587031B4BC6661DE921EDE244B3E0C2830EE5CA6/1465382675874 into the tree: key=B9AB1A (this is bundle #6, now total of 7 bundles, 0 ignored) Inserted 4260F9BD1918629809A513594D0B4F6CCF077B3E6A154D791A1EF73AAA2AC2D2/59 into the tree: key=78DED7 (this is bundle #7, now total of 8 bundles, 0 ignored) Inserted 0A3D926DD3DD871D41B4C14A6819C32D75DB243598D590A7678A4B36FC8540FE/24 into the tree: key=FEB473 (this is bundle #8, now total of 9 bundles, 0 ignored) Inserted 9C6CF3DDF64DB1B254D7768E3412F91C7E204FD13475D6119699A7D5EA172857/25 into the tree: key=23B4F0 (this is bundle #9, now total of 10 bundles, 0 ignored) Inserted C9BE55808B4BC1E418790F0E38A8A9DFB786C16F08B3F54E20081258008ED415/35 into the tree: key=A33A24 (this is bundle #10, now total of 11 bundles, 0 ignored) Inserted B4BA7DC1E4A299A4ED0C05E4691ABB6F8C281993E81BDC7F4B936B804EC0B290/64 into the tree: key=F71B85 (this is bundle #11, now total of 12 bundles, 0 ignored) Inserted 38D4CECFB48DC7100AAC216F1F293BDDA901A8B507CA0D7FDEE707681E619906/1464067754787 into the tree: key=230576 (this is bundle #12, now total of 13 bundles, 0 ignored) Inserted 5B59C253902C33236E23553799EF5119BE958B2DCAFBD7DBC11609F51CD2D517/15 into the tree: key=30916D (this is bundle #13, now total of 14 bundles, 0 ignored) Inserted DBDA4EF86159EE3581B15791AB481AD23C8AE020EE8BC45A3285EB097272968F/52716261 into the tree: key=92E7C4 (this is bundle #14, now total of 15 bundles, 0 ignored) Inserted 6A1925F0879A9ED546DF1E82348CFBAD9CAFEBD72F621613CCD4DD08886C950D/13 into the tree: key=EAA68C (this is bundle #15, now total of 16 bundles, 0 ignored) Inserted 37E64992F20DA795935B98B7B2FDF382F2BF94224F6811815A51DCCBFBBD02DE/9 into the tree: key=B40F75 (this is bundle #16, now total of 17 bundles, 0 ignored) Inserted 399EDD5EFB6F911020A724064601B37902260F1775520EC354FCD73617A29AF8/55 into the tree: key=FDE0D9 (this is bundle #17, now total of 18 bundles, 0 ignored) Inserted 9A09EC873F402423D4A6AF19DC5342F4B7937C75E7DA366FDF3676FA0AB8F80F/1464067764151 into the tree: key=5C108B (this is bundle #18, now total of 19 bundles, 0 ignored) Inserted A5B373DB9AEDDE766CD0FA25F83BA36E96F91A298D5F8A9353700B592AC49D6C/386301 into the tree: key=B76BD5 (this is bundle #19, now total of 20 bundles, 0 ignored) Inserted 5B6AA45BF1212FDB376BC7231C1C61C1DF118E32774788A53AA895E50D7EB775/387197 into the tree: key=B68DAA (this is bundle #20, now total of 21 bundles, 0 ignored) ** TXing every 1000+1d250ms, ratio=0.000 (0+0) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4)

gardners commented 8 years ago

Hello,

Hmm... it does indeed seem to not be receiving anything from the radio, but the log at 230400bps shows that the radio has clearly been flashed with our firmware, and it sending its heart-beats to the MR3020 (you are using it with an MR3020?).

Are you able to try connecting the radio to another device? Has /dev/ttyATH0 been removed or commented out from /etc/inittab? The reason I ask, is that it looks like the radio is not reliably receiving characters from the MR3020. Can you check the solder joints/connections between the MR3020 to the radio? It might be that the TX line from the MR3020 is no longer reliably connected to the RFD900. Can you post an image of your hardware setup?

Paul.

On Wed, Jun 29, 2016 at 11:50 PM, cowherdboy notifications@github.com wrote:

I am still unable to get +++ to work. Please see if my minicom configuration is correct [image: minicom] https://cloud.githubusercontent.com/assets/6798969/16455342/8911aa1c-3e46-11e6-9b1c-607f277e326e.jpg

I waited 2 seconds, typed +++, and waited for more than 2 seconds but there were no OK received.

I am still unable to see the peer across the UHF link (if there is one). This is the lbard command that is running when I do a ps: /serval/lbard 127.0.0.1:4110 lbard:lbard 8711C2E38EF95D4785C37243FBB904C8BE43C4BCF795EE07A4DA57517A5CA245 /dev/ttyATH0 rebootwhenstuck timeslave udptime logrejects meshmsonly

When I ran the command with radio I got the following: /serval/lbard 127.0.0.1:4110 lbard:lbard 8711C2E38EF95D4785C37243FBB904C8BE43C4BCF795EE07A4DA57517A5CA245 /dev/ttyATH0 radio Version 20160616.0320.1 Serial port settings before tcsetaddr: c=000018b3, i=00000000, o=00000000, l=00000000 Serial port settings attempting ot be set: c=000018b3, i=00000000, o=00000000, l=00000000 Serial port settings after tcsetaddr: c=000018b3, i=00000000, o=00000000, l=00000000 Serial port open as fd 4 My SID prefix is 8711C2E38EF9

Inserted 2BD64BF074A8B0250C72DA7446D580F4D69980C3B13587EAC932E63C256AFF12 /1463371086659 into the tree: key=528215 (this is bundle #0, now total of 1 bundles, 0 ignored) Inserted 6A7D848F999FFC089062AABF8C8820822F8218A5C402D2E0CFB38177C68EEAD8/9 into the tree: key=FB10E2 (this is bundle #1 https://github.com/servalproject/mesh-extender-builder/issues/1, now total of 2 bundles, 0 ignored) Inserted 75C8320B2F046E363E5A453902DAE0FBC20002732FD70E492B0C0D073538904E /33 into the tree: key=B2F604 (this is bundle #2 https://github.com/servalproject/mesh-extender-builder/issues/2, now total of 3 bundles, 0 ignored) Inserted ABCB428560FEC2CCC6EFB36B15F4D2C2E768533A5A071C15457F0E76B089BDD1/9 into the tree: key=F127E6 (this is bundle #3 https://github.com/servalproject/mesh-extender-builder/issues/3, now total of 4 bundles, 0 ignored) Inserted 2149FC59636BAED06E7361AC8629CEC36E77054683D3C9671BA46A683805C558 /52 into the tree: key=AFDF68 (this is bundle #4 https://github.com/servalproject/mesh-extender-builder/issues/4, now total of 5 bundles, 0 ignored) Inserted F453005BA71C2B71FB549D6F3ECCADB0F0BA4FA2E729A9EE85A6D6DEF097F75F/13 into the tree: key=603DC9 (this is bundle #5 https://github.com/servalproject/mesh-extender-builder/issues/5, now total of 6 bundles, 0 ignored) Inserted 82C1FF7E0B585D39FF7BA0E0587031B4BC6661DE921EDE244B3E0C2830EE5CA6 /1465382675874 into the tree: key=B9AB1A (this is bundle #6 https://github.com/servalproject/mesh-extender-builder/issues/6, now total of 7 bundles, 0 ignored) Inserted 4260F9BD1918629809A513594D0B4F6CCF077B3E6A154D791A1EF73AAA2AC2D2/59 into the tree: key=78DED7 (this is bundle #7 https://github.com/servalproject/mesh-extender-builder/issues/7, now total of 8 bundles, 0 ignored) Inserted 0A3D926DD3DD871D41B4C14A6819C32D75DB243598D590A7678A4B36FC8540FE /24 into the tree: key=FEB473 (this is bundle #8 https://github.com/servalproject/mesh-extender-builder/issues/8, now total of 9 bundles, 0 ignored) Inserted 9C6CF3DDF64DB1B254D7768E3412F91C7E204FD13475D6119699A7D5EA172857/25 into the tree: key=23B4F0 (this is bundle #9, now total of 10 bundles, 0 ignored) Inserted C9BE55808B4BC1E418790F0E38A8A9DFB786C16F08B3F54E20081258008ED415 /35 into the tree: key=A33A24 (this is bundle #10, now total of 11 bundles, 0 ignored) Inserted B4BA7DC1E4A299A4ED0C05E4691ABB6F8C281993E81BDC7F4B936B804EC0B290/64 into the tree: key=F71B85 (this is bundle #11, now total of 12 bundles, 0 ignored) Inserted 38D4CECFB48DC7100AAC216F1F293BDDA901A8B507CA0D7FDEE707681E619906 /1464067754787 into the tree: key=230576 (this is bundle #12, now total of 13 bundles, 0 ignored) Inserted 5B59C253902C33236E23553799EF5119BE958B2DCAFBD7DBC11609F51CD2D517/15 into the tree: key=30916D (this is bundle #13, now total of 14 bundles, 0 ignored) Inserted DBDA4EF86159EE3581B15791AB481AD23C8AE020EE8BC45A3285EB097272968F /52716261 into the tree: key=92E7C4 (this is bundle #14, now total of 15 bundles, 0 ignored) Inserted 6A1925F0879A9ED546DF1E82348CFBAD9CAFEBD72F621613CCD4DD08886C950D/13 into the tree: key=EAA68C (this is bundle #15, now total of 16 bundles, 0 ignored) Inserted 37E64992F20DA795935B98B7B2FDF382F2BF94224F6811815A51DCCBFBBD02DE /9 into the tree: key=B40F75 (this is bundle #16, now total of 17 bundles, 0 ignored) Inserted 399EDD5EFB6F911020A724064601B37902260F1775520EC354FCD73617A29AF8/55 into the tree: key=FDE0D9 (this is bundle #17, now total of 18 bundles, 0 ignored) Inserted 9A09EC873F402423D4A6AF19DC5342F4B7937C75E7DA366FDF3676FA0AB8F80F /1464067764151 into the tree: key=5C108B (this is bundle #18, now total of 19 bundles, 0 ignored) Inserted A5B373DB9AEDDE766CD0FA25F83BA36E96F91A298D5F8A9353700B592AC49D6C/386301 into the tree: key=B76BD5 (this is bundle #19, now total of 20 bundles, 0 ignored) Inserted 5B6AA45BF1212FDB376BC7231C1C61C1DF118E32774788A53AA895E50D7EB775 /387197 into the tree: key=B68DAA (this is bundle #20, now total of 21 bundles, 0 ignored) ** TXing every 1000+1d250ms, ratio=0.000 (0+0) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4) * TXing every 1000+1d250ms, ratio=0.154 (0+4)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8#issuecomment-229370675, or mute the thread https://github.com/notifications/unsubscribe/AAonT_oLraS3lJAxpcoxNPQpsSnyCK6Bks5qQn8pgaJpZM4I6kh6 .

cowherdboy commented 8 years ago

Hi Paul,

Yes, the flash900.log shows that we are able to reliably communicate with the module. I killed the lbard threads and launched minicom. The +++ worked and I got into AT command mode. The /etc/inittab shows the follwing on line #3: #ttyATH0::askfirst:/bin/ash --login

Perhaps lbard is locking entry into AT command mode? I am using both MR3020 and MR3040 and they both behave the same way.

gardners commented 8 years ago

Hello,

Ah, I didn't realise you were leaving lbard running while trying to talk to the radio. You must have only one thing talking to the serial port at a time, or it will not work for all sorts of reasons.

Paul.

On Thu, Jun 30, 2016 at 11:37 AM, cowherdboy notifications@github.com wrote:

Hi Paul,

Yes, the flash900.log shows that we are able to reliably communicate with the module. I killed the lbard threads and launched minicom. The +++ worked and I got into AT command mode. The /etc/inittab shows the follwing on line

3 https://github.com/servalproject/mesh-extender-builder/issues/3:

ttyATH0::askfirst:/bin/ash --login

Perhaps lbard is locking entry into AT command mode? I am using both MR3020 and MR3040 and they both behave the same way.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8#issuecomment-229540890, or mute the thread https://github.com/notifications/unsubscribe/AAonT6Hos9J6ZbifipTUfaJJ5OGNIT74ks5qQyTMgaJpZM4I6kh6 .

cowherdboy commented 8 years ago

I can send text to the 2nd radio via minicom now. However, with lbard I am still unable to see the peer over the UHF via the Serval App. What can I do to troubleshoot this connectivity issue?

gardners commented 8 years ago

I'd suggest:

Kill lbard on both ends, and use minicom on both, and try typing some stuff in one, and then !! to cause it to send to the other, and see if it gets there. Try from each end.
Verify that they both have the same ATS= settings.

Paul.

On Thu, Jun 30, 2016 at 8:19 PM, cowherdboy notifications@github.com wrote:

I can send text to the 2nd radio via minicom now. However, with lbard I am still unable to see the peer over the UHF via the Serval App. What can I do to troubleshoot this connectivity issue?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8#issuecomment-229625359, or mute the thread https://github.com/notifications/unsubscribe/AAonT0AmU9rDURP9QENlhr596oI4vzCFks5qQ58tgaJpZM4I6kh6 .

cowherdboy commented 8 years ago

I tried this and was able to receive on both sides.
Where can I find the ATS settings?

gardners commented 8 years ago

Hello,

If both sides receive packets with !!, then in theory, it is working.

Use +++, and then type: ATI5

Paul.

On Thu, Jun 30, 2016 at 9:22 PM, cowherdboy notifications@github.com wrote:

I tried this and was able to receive on both sides.

Where can I find the ATS settings?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8#issuecomment-229636662, or mute the thread https://github.com/notifications/unsubscribe/AAonT0mzgcTrtNK2QqNGYjNdMmtmPozGks5qQ63kgaJpZM4I6kh6 .

cowherdboy commented 8 years ago

This is the ATI5 output:

ATI5 0:FORMAT=26 1:SERIAL_SPEED=230 2:AIR_SPEED=128 3:NETID=16656 4:TXPOWER=1 5:ECC=0 6:OPPRESEND=0 7:FREQ=923000 8:DUTY_CYCLE=100 9:LBT_RSSI=80 10:MANCHESTER=0 11:RTSCTS=0

gardners commented 8 years ago

Is it the same on both radios?

Paul.

On Fri, Jul 1, 2016 at 9:40 AM, cowherdboy notifications@github.com wrote:

This is the ATI5 output:

ATI5 0:FORMAT=26 1:SERIAL_SPEED=230 2:AIR_SPEED=128 3:NETID=16656 4:TXPOWER=1 5:ECC=0 6:OPPRESEND=0 7:FREQ=923000 8:DUTY_CYCLE=100 9:LBT_RSSI=80 10:MANCHESTER=0 11:RTSCTS=0

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8#issuecomment-229822582, or mute the thread https://github.com/notifications/unsubscribe/AAonT58YIh5XB44dxUogXYdT2sJ9Iw-0ks5qRFrngaJpZM4I6kh6 .

cowherdboy commented 8 years ago

Yes, it is the same on both.

gardners commented 8 years ago

... and do you have suitable antennae on each? Are they physically quite close (the default TX power is only 1mW, to avoid regulatory issues, as this firmware DOES NOT frequency hop, and use at higher power levels will most likely require a special spectrum license in most countries. This is why we are moving to the RFD900X that can qualify under a different exemption.)

Paul.

On Fri, Jul 1, 2016 at 11:55 AM, Paul Gardner-Stephen < paul@servalproject.org> wrote:

Is it the same on both radios?

Paul.

On Fri, Jul 1, 2016 at 9:40 AM, cowherdboy notifications@github.com wrote:

This is the ATI5 output:

ATI5 0:FORMAT=26 1:SERIAL_SPEED=230 2:AIR_SPEED=128 3:NETID=16656 4:TXPOWER=1 5:ECC=0 6:OPPRESEND=0 7:FREQ=923000 8:DUTY_CYCLE=100 9:LBT_RSSI=80 10:MANCHESTER=0 11:RTSCTS=0

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8#issuecomment-229822582, or mute the thread https://github.com/notifications/unsubscribe/AAonT58YIh5XB44dxUogXYdT2sJ9Iw-0ks5qRFrngaJpZM4I6kh6 .

cowherdboy commented 8 years ago

It looks like the Mesh Extender units are able to see each other as per the output below (it is registering the peer). However this is not reflected on the Serval App. I am using version 0.93 of the app.

root@Serval-MeshExtender-0:~# lbard monitor /dev/ttyATH0 Version 20160616.0320.1 Serial port settings before tcsetaddr: c=00001cb3, i=00000000, o=00000004, l=00000a20 Serial port settings attempting ot be set: c=00001cb3, i=00000000, o=00000004, l=00000a20 Serial port settings after tcsetaddr: c=00001cb3, i=00000000, o=00000004, l=00000a20 Serial port open as fd 4 My SID prefix is 000000000000 * TXing every 1000+1d250ms, ratio=0.000 (0+0) Registering peer 8711c2e38ef9* *\ TXing every 500+1d125ms, ratio=0.115 (3+0) * TXing every 250+1d62ms, ratio=0.231 (6+0) * TXing every 150+1d31ms, ratio=0.231 (6+0) * TXing every 150+1d25ms, ratio=0.231 (6+0) * TXing every 150+1d25ms, ratio=0.192 (5+0) * TXing every 150+1d25ms, ratio=0.154 (4+0) * TXing every 150+1d25ms, ratio=0.231 (6+0) * TXing every 150+1d25ms, ratio=0.192 (5+0) * TXing every 150+1d25ms, ratio=0.115 (3+0) * TXing every 150+1d25ms, ratio=0.154 (4+0) * TXing every 150+1d25ms, ratio=0.154 (4+0) * TXing every 153+1d38ms, ratio=0.269 (7+0) * TXing every 150+1d25ms, ratio=0.154 (4+0) * TXing every 150+1d25ms, ratio=0.115 (3+0) * TXing every 150+1d25ms, ratio=0.154 (4+0) * TXing every 150+1d25ms, ratio=0.154 (4+0)

gardners commented 8 years ago

Hello,

Ah, okay. That makes much more sense. lbard doesn't tell servald that there are peers reachable (yet). Rhizome (and hence MeshMS messages) will be carried, but you won't know that the person is in range. Try sending a MeshMS message, and confirm that it delivers fine. If rhizome is otherwise quiescent, the message should deliver in somewhat less than a minute.

Note that there is /etc/serval/manuallbard as a convenience script for when you want to run lbard in the foreground, and monitor what it is doing.

Paul.

On Fri, Jul 1, 2016 at 1:38 PM, cowherdboy notifications@github.com wrote:

It looks like the Mesh Extender units are able to see each other as per the output below (it is registering the peer). However this is not reflected on the Serval App. I am using version 0.93 of the app.

root@Serval-MeshExtender-0:~# lbard monitor /dev/ttyATH0 Version 20160616.0320.1 Serial port settings before tcsetaddr: c=00001cb3, i=00000000, o=00000004, l=00000a20 Serial port settings attempting ot be set: c=00001cb3, i=00000000, o=00000004, l=00000a20 Serial port settings after tcsetaddr: c=00001cb3, i=00000000, o=00000004, l=00000a20 Serial port open as fd 4 My SID prefix is 000000000000 * TXing every 1000+1d250ms, ratio=0.000 (0+0) Registering peer 8711c2e38ef9* *\ TXing every 500+1d125ms, ratio=0.115 (3+0) * TXing every 250+1d62ms, ratio=0.231 (6+0) * TXing every 150+1d31ms, ratio=0.231 (6+0) * TXing every 150+1d25ms, ratio=0.231 (6+0) * TXing every 150+1d25ms, ratio=0.192 (5+0) * TXing every 150+1d25ms, ratio=0.154 (4+0) * TXing every 150+1d25ms, ratio=0.231 (6+0) * TXing every 150+1d25ms, ratio=0.192 (5+0) * TXing every 150+1d25ms, ratio=0.115 (3+0) * TXing every 150+1d25ms, ratio=0.154 (4+0) * TXing every 150+1d25ms, ratio=0.154 (4+0) * TXing every 153+1d38ms, ratio=0.269 (7+0) * TXing every 150+1d25ms, ratio=0.154 (4+0) * TXing every 150+1d25ms, ratio=0.115 (3+0) * TXing every 150+1d25ms, ratio=0.154 (4+0) * TXing every 150+1d25ms, ratio=0.154 (4+0)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8#issuecomment-229849552, or mute the thread https://github.com/notifications/unsubscribe/AAonT1_5jnDtPsFkaNqsiU1i7hpTXwLJks5qRJLMgaJpZM4I6kh6 .

cowherdboy commented 8 years ago

Thanks for all your help Paul. I can get it to work on the Serval App now. However, I had to peer the 2 handphones over WiFi and send a message before I could send the MeshMS message over UHF. Is there a way to manually enter the serval ID of the destination in the Serval App?

lakeman commented 8 years ago

We are working on a broadcast method for offline peer discovery, but it doesn't exist yet.

On Fri, Jul 1, 2016 at 7:02 PM, cowherdboy notifications@github.com wrote:

Thanks for all your help Paul. I can get it to work on the Serval App now. However, I had to peer the 2 handphones over WiFi and send a message before I could send the MeshMS message over UHF. Is there a way to manually enter the serval ID of the destination in the Serval App?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8#issuecomment-229902469, or mute the thread https://github.com/notifications/unsubscribe/AAkD3j28ytwK6p1Aj4AOyGydCJaKkwiHks5qRN7BgaJpZM4I6kh6 .

gardners commented 8 years ago

Hello,

Great to hear :) The ability to find peers for messaging over UHF and other slow links is something that we are planning to do, hopefully this will be in place by the end of the year, as we keep shaking down the UHF links and Mesh Extender in general.

Paul.

On Fri, Jul 1, 2016 at 7:02 PM, cowherdboy notifications@github.com wrote:

Thanks for all your help Paul. I can get it to work on the Serval App now. However, I had to peer the 2 handphones over WiFi and send a message before I could send the MeshMS message over UHF. Is there a way to manually enter the serval ID of the destination in the Serval App?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8#issuecomment-229902469, or mute the thread https://github.com/notifications/unsubscribe/AAonT7wzN4lnrPT1BMqvbt9xRHzgLyPLks5qRN7BgaJpZM4I6kh6 .

cowherdboy commented 8 years ago

Thanks Paul for developing such a great system. I understand it is a work in progress. In summary, I had to ensure the following to get a working system: 1) Copy firmware file in the build directory (/servald) to /serval directory on the USB drive as the file was missing. 2) Serval App does not support finding peer over UHF yet. Hence, need to pre-register devices over WiFi to get the Serval ID registered. 3) To see if the peer is visible, I can run lbard monitor /dev/ttyATH0 and see if the peer is being registered.

For troubleshooting and testing over Minicom: 1) Kill lbard 2) Launch minicom -s and set baud rate at 230400 (to match UHF module's baud rate). The baud rate of the UHF's module can be seen on the flash900.log file that is located in the /dos directory 3) Whatever typed on the minicom console followed by !! should appear on the peer's minicom console 4) Type +++ to enter into AT command mode. Need to exit AT command mode for (3) to work.

gardners commented 8 years ago

Hello,

Thanks for providing the succinct summary for future readers.

I'll look into why the firmware wasn't in the correct place, as this should not be the case.

Paul.

On Mon, Jul 4, 2016 at 12:25 PM, cowherdboy notifications@github.com wrote:

Closed #8 https://github.com/servalproject/mesh-extender-builder/issues/8.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8#event-711566596, or mute the thread https://github.com/notifications/unsubscribe/AAonT82aipl-DjeIno34UVunBuPOxCggks5qSHY1gaJpZM4I6kh6 .

gbaweja commented 5 years ago

Hello Paul,

I am having kind of same issue. I am using Ubuntu 16.04. I downloaded the repository but make install gave error. So without installing any software or firmware on Ubuntu Linux. I installed minicom.

I have RFD 900+ radio. When I am on Minicom terminal window and I type "AT" as AT commands to see whats going on with the radio. I do not have anything back, I mean I do not get "OK". Could you please help me here, as I need help urgently.

Thank you for your time and help.

pdl86 commented 5 years ago

Hello

same issue there with a custom Linux. connection attempt to the modem via microcom or minicom , work ONCE and only once . Afterward no response to +++ . The very same modems works with RFDToos on a PC, even fi behavior between tag ( settings / terminal / RSSI) is not straighforward and hand depending of the acess order. It works correctly with Putty / serial on Windows.

It seems that a "reset" is neeed to establish the rs232 link over linux

gardners commented 5 years ago

sorry for not responding to this one earlier. Can either of you provide a complete detailed use-case that will let me reproduce this as easily as possible?

Thanks, Paul.

pdl86 commented 5 years ago

Hello

I realize that the issue is not strictly related to your project, but any help is appreciated.

the goal of our project is to extend a Lora network by establishing a serial link based on RDdesign modems between two Lora packet forwarder , based on multitech conduit.

as we have issue with basic , minicom test, we have tried to debug with a multitech/modem on one end, a PC/Modem on the other end .

PC end:

on one hand a RFD868x firmware 2.6 , connected via a USB cable via a USB adapter ( to ftdi) , to a PC running RFDTools 2.6 (from RF design) the modem is powered via the usb cable ( this in order to keep the modem control) 57600, 8, N, 1 no flow control

Mutitech end:

at the other end , a Multitech conduit , running mlinux 4.0.1 ( based on Openembedded linux), with minicom 2.7 and microcom (BusyBox v1.24.1) connected via a Serial port ( DCE) , via a serial cable to the 868x modem ( GND/VCC,TX/RX/CTS/RTS) , and external 5V power

57600, 8, N, 1 no flow control ( neither hardware nor software)

the very first time we have connected the Multitech to the modem on minicom ( and the very first on microcom ) we have been able to issue a +++ , ( OK appeared only on microcom) , and then issue ATI and RT command ( hence to the remote modem). After closing minicom ( microcom) and reopening it , nothing. even after rebooting the multitech machine : nothing

BUT STRANGE : if a minicom ( microcom) session is opened on the modem, if you issue on the other hand a command as RT&T=RSSI ( debug rssi on the remote modem) ( on the RFDTools, terminal tag /window) then the minicom / microcom correctly receive the data from teh lcoal modem and display them .

Even stranger

two Mutlitech , each with a serial card, a 868x modem , connected via a serial cable + external 5V power, the modems are linked together ( solid green) open minicom on each : no return on +++, ATI , .. , but if you issue RT&T=RSSI on one multitech, then the OTHER display the command in fact the remote display ALL command issued on the other machine. and this also the other way around

It looks as if in this mode , the modem does not understand at all the +++ , and then only transmit the data to the other end. which is effectively the case the +++ display at the other end.

Note that on the pc , the RFDTools behavior is a little bit strange too. when you start it , set up the comport, the issue a request to load the setting, then when switching to the terminal tabs, you 've got "Cant open serial port". , and returning to "setting" you then get ""Invalid Comport or in use" but when starting RFD tools if you directly go to the terminal tab, it states : "opened port" and you can issue AT command, and then switching to the settings tabs you can load setting , ...

In fact also on the PC , if trying to use a term emulator ( I.e putty) , the +++ command is only interpreted correctly the very first time, never again since. in order to use it , you have to issue the +++ command in the terminal tag of the RFD tools first Any help will be greatly appreciated.

Looking forward to read you

Bets regards philippe

Le 08/01/2019 à 00:42, gardners a écrit :

sorry for not responding to this one earlier. Can either of you provide a complete detailed use-case that will let me reproduce this as easily as possible?

Thanks, Paul.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8#issuecomment-452122340, or mute the thread https://github.com/notifications/unsubscribe-auth/AcwIu8Uw6DrnFq9bIKGN2LDbAcfbdYXlks5vA9tOgaJpZM4I6kh6.

ee

gardners commented 5 years ago

Okay, that is indeed off-topic for this issue, so I will close it again.
But as for helping you find a solution, I would recommend instrumenting the serial links, and having a 3rd RFD900 as a passive listener, so that you can work out what commands are getting where.

But more generally, why use an RFD900 to range extend LoRa, when LoRa is likely to have greater range than an RFD900 to begin with? If you would like more detailed help, email me, and we may be able to come to some arrangement.

Paul.

pdl86 commented 5 years ago

Hello Paul

thanks for your "help".

a) why use an RFD900 ... : we need to establish a point to point link, in the 915/868 Mhhz band, with (likely ) at leat 128k/bit/sec / large payloads , and NOT using LPWAN technologies (Lora, NBIoT, Sigfox ), with reasonable encryption ( AES) .. in order to be relatively "stealth".

hence we have the idea to use technology coming from a different fields ( Drones) , with "proven" ability to establish long distance link (several km) at relatively high bandwidth.

and the the RFD900x modem pops up as matching all requirements on paper. ( and for the time being on our test platform ,except this AT mode issue)

We will operate in area where the compliance to ETSI / FCC is not really an issue ( mining industries in the middle of nowhere) off course if coming back in Europe , we will have to "downgrade" our links

b) again the problem is not to establish the link ( which works well ( IP link established between the two gateway and stable ) , but to communicate with the modem to pass AT command on the LInux boxes with either minicom or microcom which we can do on a PC with the RFD design modem tools) . as states we are able to open minicom terminal at both ends, not being able to pass in AT mode ( ++++ does not return anything) , but when issuing a command on one end (for the other one) we see it on the remote terminal : confirm that we are in data transmission mode.

So we suspect that there is a reset "command" to send to the modem to enable it to understand the "+++" command.

LAST UPDATE : it seems it is working much better when speed is set-up at 115200 bauds ( all above minicom test were done at 57600). ( the only other different thing is that the remote modem is still transmitting data

I'm now able to take over the modem ( +++ return OK ) and vice versa ( restore the data link) .

Did you ever see this behavior

any helps is appreciated ( as it is now "working" do not spend to much time on it)

Best regards Philippe

Le 11/01/2019 à 04:16, gardners a écrit :

Okay, that is indeed off-topic for this issue, so I will close it again. But as for helping you find a solution, I would recommend instrumenting the serial links, and having a 3rd RFD900 as a passive listener, so that you can work out what commands are getting where.

But more generally, why use an RFD900 to range extend LoRa, when LoRa is likely to have greater range than an RFD900 to begin with? If you would like more detailed help, email me, and we may be able to come to some arrangement.

Paul.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/servalproject/mesh-extender-builder/issues/8#issuecomment-453362007, or mute the thread https://github.com/notifications/unsubscribe-auth/AcwIu3u01ksJkTEPw3oInQdwztvWIg28ks5vCAHwgaJpZM4I6kh6.

pdl86 commented 5 years ago

Hello Paul

CORRECTION : again it has worked once, and then no more. !! It's magic ! ( but in the right way)

regards philippe