Possibility to adapt code for the T-Beam ?

[TomF8COD]

Hello, I'm trying to figure out how to adapt the code to the ttgo tbeam as it seems a nice device for aprs use. I've disabled the aprsIS and wifi part to be able to fit the code in the tbeam, the idea is to only use it as a kiss radio modem, without gateway feature for now. I've changed the lora module pins to fit the t-beam. It pairs with aprsdroid and send a lora packet as far as I can see on the sdr. But the lora32-v2 using the lora-aprs/LoRa_APRS_iGate code doesn't decode the packet (it does when I'm using OE5BPA tracker code). As I am a total noob in development, I thought I should ask if you have any idea or suggestion I could try to make the code run on the t-beam. This device and aprsdroid would be a good match for a very nice aprs package if it can be adapted. Thanks for any help and for the work you already did ! 73 de Tom F8COD

[sh123]

Hello, Tom, unfortunately, they are not interoperable on protocol level even if all LoRa parameters match, LoRa_APRS_iGate sends plain text APRS messages, this project is using AX.25 UI frames as per APRS specification page 12, this is needed to be interoperable with classical Linux APRS software, such as Xastir and other Linux or Windows APRS tools.

Client mode can be interoperable if Bluetooth client sends raw APRS messages over KISS. APRSDroid supports plain text APRS messages, but not over KISS. It uses new line delimiter to separate messages, so you cannot send any binary data in this case or need to perform additional encoding such as Base64.

I can add option to disable KISS, in this case they will be interoperable if you will select "TNC (plaintext TNC2)" in APRSDroid protocol options, or add option to convert AX.25 to raw and send them over to LoRa.

IMHO, AX.25 UI is the way to go with APRS over LoRa as it enables succession and interoperability with classical mature APRS clients, so less work on client/tracker side and no need to reinvent the wheel - just implement the modem and use your existing favorite APRS software, such as APRSDroid or Xastir, so it could be used not only for tracking, but also messaging through IS-RF TX capable iGate.

73!

[TomF8COD]

Thank you for your answer ! I agree for AX.25 it's the good way to go. I'll check the sync word on the iGate, I'll keep you posted if I can make it work.

73 !

[sh123]

I can add dynamic incoming packet type detection and convert them to ax25, outgoing packet conversion will need some configuration parameter, so app will know that it needs to convert to raw from ax25 before sending.

[TomF8COD]

Don't worry, as I'm not sure of what I'm doing yet I don't want to give you more work :smile:
What I'm thinking about right now, is to put the simplified code on another t-beam that I could use as a kiss modem on a linux computer. So I'll run the gateway on the computer itself (with xastir), and see if I can exchange packets between aprsdroid with t-beam1 on one side and linux with t-beam2 on the other side. It would make a "lightweight" version of the code that could run on small platforms, making a minimalist tracker with aprsdroid and the same "modem" could be use as a gateway on a small computer or raspberry. I don't know if it's a good idea, It's just something that came to my mind while talking about it with other hams that are getting their feet in lora aprs. The point that I like in your code is the possibility to send messages to others stations, this is what is missing from the simple tracker codes I've tried, and if I can recall this rely on AX.25 ?

[sh123]

If you need very lightweight solution without using esp32, then check https://github.com/sh123/nrf24l01_arduino_kiss_modem, this is lightweight single sketch KISS modem, it uses Arduino Beetle and can operate through USB (including USB OTG on Android with APRSDroid), you will need similar approach, but use LoRa library instead of nrf24l01, just make a branch and modify for LoRa usage, I can help with that, but do not have hardware to test.

Linux software is using AX.25 for APRS over KISS, so I doubt it will be interoperable with LoRa_APRS_iGate if they won't add support for AX.25.

[TomF8COD]

Oh I didn't see it! Of course, it will be easier like that, I'm going to take a look at it right now. Thank you very much!

Le lun. 1 févr. 2021 à 15:04, sh123 notifications@github.com a écrit :

If you need very lightweight solution without using esp32, then check https://github.com/sh123/nrf24l01_arduino_kiss_modem, this is lightweight KISS modem, it uses (Arduino Beetle]( https://www.dfrobot.com/product-1075.html) and can operate through USB (including USB OTG on Android with APRSDroid), you will need similar approach, but use LoRa library instead of nrf24l01, just make a branch and modify for LoRa usage.

Linux software is using AX.25 for APRS over KISS, so I doubt it will be interoperable with LoRa_APRS_iGate if they wont' add support for AX.25.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sh123/esp32_loraprs/issues/11#issuecomment-770879806, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASNTJC4N32NDZ2KGLYBU2KLS42YFBANCNFSM4W3VFQ7A .

[TomF8COD]

In the meantime, I've put the code I modified on another t-beam with another phone and I can make the two aprsdroid talk together, they see each other's position and can exchange messages. I'm happy :+1: I'll try to work with the other code too, it's a good way to learn :wink:

[sh123]

Oh, good to hear, also, try to run https://github.com/sh123/codec2_talkie for DV voice communication.

[TomF8COD]

It's on my shopping list :) Thanks for all this work. Do you want me to close the issue or do you do it ?

Le lun. 1 févr. 2021 à 15:35, sh123 notifications@github.com a écrit :

Oh, good to hear, also, try to run https://github.com/sh123/codec2_talkie for voice communication :)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sh123/esp32_loraprs/issues/11#issuecomment-770902219, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASNTJC3RQ5IQPV34GH4WNQDS42335ANCNFSM4W3VFQ7A .

[sh123]

@TomF8COD, what was the change to adopt it for T-Beam usage (pinouts redefined?) so I can update README with instructions if someone else will need to use it for this device.

[TomF8COD]

Hi, I've made a fork and a branch "no_wifi" here : https://github.com/RadioHome/esp32_loraprs

Basicaly, I've stripped everything for the wifi, the beacon, the digipeater. As the purpose is to use it as a simple kiss tnc I figured I'll be able to use this feautures on the applications that are using the tnc. I've been able to test it with xastir (kiss tnc, not as ax25 tnc yet) configured as an iGate, it works perfectly.

I'm going to do some tests with the coding rate, it seems that I loose the link between my tracker and my base sooner with CR7 than with CR5. If I'm right, the transmission is a little bit longer with cr7 as it encodes on 7 bits, I don't know if it's just a one time glitch, or if it is critical for mobile use. I've seen that Fossasat-1 is using CR5 too, so I thought if it's good for a satellite, it's good for my wheelchair or my car ^^ PS : I tested it with the same pinout on a t-beam and a lora32 oled v2.

Le mer. 3 févr. 2021 à 08:33, sh123 notifications@github.com a écrit :

@TomF8COD https://github.com/TomF8COD, what was the change to adopt it for T-Beam usage so I can update README with instructions?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sh123/esp32_loraprs/issues/11#issuecomment-772300819, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASNTJCYZLJW2RDVNLCSBDZLS5D34VANCNFSM4W3VFQ7A .

[sh123]

@TomF8COD , I've added single sketch arduino tnc kiss modem, adopted from nrf sketch, https://github.com/sh123/lora_arduino_kiss_modem, that's for very lightweight usage on Arduino Nano/Uno/Beetle.

[TomF8COD]

Awesome ! Thank you very much ! I was thinking about doing it, but I'm not efficient as you are, I have no coding experience, I'm more a tinkerer ;-)

[sh123]

@TomF8COD , I do not have hardware yet to test sketch, was thinking about very small modem (RA module + Arduino Beetle), which plugs directly into the Android USB OTG (kind of phone extension with 3d printed case, which also powered from USB) and use it with APRSDroid for tracking/messaging and DV communication with codec2_talkie. However, having separate module with Bluetooth is also nice, because whole modem could be elevated higher or placed outdoors to get better coverage. Same with server part, which could operate through WiFi, so it could be placed on the roof, no coax cables - no losses.

[TomF8COD]

That's a good idea, I was just talking with a friend a few minutes ago, he has these lora modules : https://www.zigbeesolutions.com/lora/ebyte-e32-433t30d-sx1278-sx1276-433mhz-109121318425631437.html with 30dbm output it would be interesting for DV application with a bit more power. We're going to try to use them. By the way, I have a question : For a device that could be used like this in aprs and DV, would there be a way to setup the lora modulation parameters (BW, SF, CR) externaly, without the need to re-flash the device ? I haven't tested DV yet, I'll try to do it this afternoon.

Le mer. 3 févr. 2021 à 13:19, sh123 notifications@github.com a écrit :

@TomF8COD https://github.com/TomF8COD , I do not have hardware yet to test sketch, was thinking about very small modem, which plugs directly into the Android USB OTG (kind of phone extension with 3d printed case) and use it with APRSDroid for tracking/messaging and DV communication with codec2_talkie.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sh123/esp32_loraprs/issues/11#issuecomment-772466667, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASNTJC7KVUAAX6QHTHD52ADS5E5LPANCNFSM4W3VFQ7A .

[sh123]

Yes, planning to add support for LoRa parameters change in esp32_loraprs modem and codec2_talkie Preferences through KISS protocol extended commands, also get signal report, so UI can show signal level as value or on S meter.

  enum Cmd {

    // generic
    Data = 0x00,
    P = 0x02,
    SlotTime = 0x03,

    // extended to modem
    Frequency = 0x10,
    Bandwidth = 0x11,
    Power = 0x12,
    SyncWord = 0x13,
    SpreadingFactor = 0x14,
    CodingRate = 0x15,
    EnableCrc = 0x16,

    // extended events from modem
    SignalLevel = 0x30,

    // end of cmds
    NoCmd = 0x80
  };

[TomF8COD]

Really cool !

Le mer. 3 févr. 2021 à 13:53, sh123 notifications@github.com a écrit :

Yes, planning to add support for LoRa parameters change in esp32_loraprs modem and codec2_talkie Preferences through KISS protocol extended commands, also get signal report, so UI can show signal level as value or on S meter.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sh123/esp32_loraprs/issues/11#issuecomment-772485466, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASNTJC4UZ6S2K3NFEYCBH3TS5FBLRANCNFSM4W3VFQ7A .

[TomF8COD]

@sh123 I've installed xastir on a raspberry pi 3 with bluetooth connection to the t-beam at boot by adding rfcomm bind 0 xx:xx:xx:xx in a systemd service file, it's running nice. Xastir have the kiss tnc under /dev/rfcomm0 and a internet server connection configured, it works as a full time igate now. I was wondering, would it be possible to implement the wifi use by a variable in the code, that could force the server mode, digi, beacon off with some #ifdef ? If you think it's worth to do, I can work on it but I'm afraid you will have to review my code as it may be sloppy, so I'll totally understand if you don't want, . The goal is to keep with the other changes you are implementing easily. I'm going to work on the lora-arduino-kiss-modem, it's a nice sketch to learn.

[sh123]

@TomF8COD , if you select client mode then wifi and other logic is disabled, no need for #ifdef-s.

  bool IsClientMode;    // true - client mode, false - server mode

That's exactly for this scenario. For example, I have two modems, one I keep at home running as iGate in server mode and take another with me configured as a client (with wifi and aprs disabled).

This is the logic, which dynamically decides which features need to be enabled/disabled at run time:

  inline bool needsAprsis() const { 
    return !config_.IsClientMode && (config_.EnableRfToIs || config_.EnableIsToRf); 
  }
  inline bool needsWifi() const { return needsAprsis(); }
  inline bool needsBt() const { return config_.IsClientMode; }
  inline bool needsBeacon() const { return !config_.IsClientMode && config_.EnableBeacon; }

[TomF8COD]

Ok I get how it works now. I really appreciate the time you're taking to explain me your code, it's nice. :+1:

[TomF8COD]

@sh123 I've tried the client mode, but it's too big for the t-beam if I keep the #include . Don't worry, I'll try to find a solution, it's a good exercise. :wink: Oh I forgot one info : The t-beam integrated led is on pin 4

[sh123]

@TomF8COD , select different partition scheme: "Minimal SPIFFS (1.9 MB APP with OTA/190KB SPIFFS)" in Arduino IDE Tools, for T-Beam LED added ifdef on pin 4. Default partition scheme gives only 1.2 MB for APP, which might be not enough, updated README with this information.

[TomF8COD]

@sh123 I was wondering where this setting was, I only see it when selecting "ESP32 Dev module" but not when I choose "t-beam" or "lora32". It's flashing, but on the serial monitor I get this : LoRa init: 433775000, 125000, 12, 5, 20, 34, 0......................... So it doesn't work. I'm going to investigate it tomorrow.

[sh123]

@TomF8COD , "T-Beam" cannot be flashed as "ESP32 Dev Module" in Arduino, they have different pinout layout, this way LoRa module cannot start, because of MOSI/MISO pinouts mimatch.

Need to modify ~/.arduino15/packages/esp32/hardware/esp32/1.0.4/boards.txt to add option for different partition layout for T-Beam as

t-beam.menu.PartitionScheme.default=Default 4MB with spiffs (1.2MB APP/1.5MB SPIFFS)
t-beam.menu.PartitionScheme.default.build.partitions=default
t-beam.menu.PartitionScheme.min_spiffs=Minimal SPIFFS (1.9MB APP with OTA/190KB SPIFFS)
t-beam.menu.PartitionScheme.min_spiffs.build.partitions=min_spiffs
t-beam.menu.PartitionScheme.min_spiffs.upload.maximum_size=1966080

and restart Arduino IDE. This way it compiles.

Do not have T-Beam to test, so If it still does not work then can add #ifdefs to cut unneeded code and make image smaller, but better to change layout as these boards have 4 MB of flash, so more space could be used with smaller SPIFFS partition or if OTA is not needed, by default there is only 1.2 MB for application.

[TomF8COD]

@sh123 Well done, I found your answer in my mail this morning as I started the computer, I had the idea to check the boards.txt to try something like that. It works perfectly ! I tried it in client mode on the t-beam, and in server mode on a ttgo-lora32-V2 running by itseland not connectedf, it seems to be ok. For the integrated led pin, I think just a declaration in config.h would be enough end indicating in comment the pin 4 for t-beam and pin 25 for ttgo-lora32-v2. What do you think about it ? If you want me to run some tests with specific settings on theses devices tell me, I have time to do it and I'll be happy to help.

And if I may ask, what is your name ?

[sh123]

@TomF8COD , changed config so that it will use lora pinout definitions and builtin led definition taken from arduino's board variant pins_arduino.h, this way it is just enough to select board in arduino and build without changing code.

T-beam defines LED as 14, TTGO-t1 as 22 and TTGO-LoRa-v1 as 2, it needs to be changed in config.h if board uses some other pinout.

[TomF8COD]

Very good, it's ways simpler like this, indeed.

[TomF8COD]

I'm starting to get a grip on git and I've worked my way into making a new branch to integrate a ssd1306 oled to display packets. Not of much use on the client, but I had already the display on my devices and it was a good exercise to make it work. On the standalone gateway it's more useful, especially during tests as we can see what's going on. I used the Adafruit ssd1306 library, but I've seen the u8g2 lib that seems good too. I've tried to activate is-to-rf on the server, but it's really heavy duty on transmitting time. It would be interesting to be able to route only messages from is to rf but not the positions, I'm going to read the protocol spec to see how it works.

[sh123]

@TomF8COD , you can just specify multiple filters, they just need to be space separated, for example

r/lat/lon/dist t/m

will accept only messages from the circle with radius dist at point lat/lon

All rules are explained here: http://www.aprs-is.net/javAPRSFilter.aspx

Packets or status on display would be nice.

[TomF8COD]

@sh123 I didn't see the t filter, it's exactly what I need. The code with the oled branch is here : https://github.com/RadioHome/esp32_loraprs It displays the packet, if it's RX or TX and where from (NET, BCN, iGate or Digi). And of course at boot it displays some infos about the configuration.

[sh123]

@TomF8COD , we can merge it, maybe just need some config parameter to disable/enable screen if board does not have it and config parameters to change pinouts.

[TomF8COD]

@sh123 I'm going to watch the config and to switch from the adafruit-ssd1306 lib to u8g2 lib that manages more screens, including the ssd1306. I try to do it soon and I come back to you ;-)

[TomF8COD]

@sh123 I've tried the u8g2 lib, but it lacks word wrap, so I haven't been able to get a clean display of the packets on the oled, I went back to ssd1306 for now. I noticed something with the digipeater, I see in ax25_payload.cpp that you insert the igate callsign defined by ownCallsign in the ax25 packet, but it doesn't seem to work. Here is what I get when I send a packet with the client tnc from F8COD-7. It should add the server callsign (my server is F8COD-10), even if it's the same call with different SID, right ? The F8COD-5 is comming out of the blue, I don't have the SID -5 configured :thinking: F8COD is xastir with the lora_arduino_kiss_modem code.

[sh123]

@TomF8COD , it should insert own callsign only when TRACE is used, for WIDE it is not inserted, also it is very simple, it does not support ?IGATE? and other queries.

[TomF8COD]

@sh123 I've worked on the code to display infos with a 0.96" SSD1306 based Oled, the tnc displays some information on start up, then it displays the received packets and when it switches to TX. If you want to look at the code it's here : https://github.com/RadioHome/esp32_loraprs I've installed the tnc on a raspberry-pi that already has my AEA PK12 for APRS and setup aprx to make a bi directional gateway between 433.775 (lora) and 144.800 (aprs) We're going to have fun here testing loraprs !

[sh123]

@TomF8COD , wow looks nice :)

[TomF8COD]

Thank you :)

Le jeu. 18 mars 2021 à 17:10, sh123 @.***> a écrit :

@TomF8COD https://github.com/TomF8COD , wow looks nice :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sh123/esp32_loraprs/issues/11#issuecomment-802054966, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASNTJC3QMFIJ4D2E7ZZ7DMLTEIQY7ANCNFSM4W3VFQ7A .