Not so much of an issue, but... about softrf HOT 21 CLOSED

Checksum issue #24 remedied this. The SoftRF now enables the Flarm menu in the Nano. I'll spend some time looking at setting the parameters appropriately & report back.

from softrf.

Make sure you've met #15
As well as baud rate, symbol/parity/stop bits, voltage levels.

from softrf.

Hi Pete,

I originally opened issue #15 which Linar refers to - and when I tried with other aircraft around me I could see the PFL* NMEA sentences. Coincidentally I also have a LXNav Nano3 and have tried to get it to see the SoftRF unit via USB connected to the Nano - no joy so far I’m afraid !

from softrf.

from softrf.

Hi

Same here - FLARM menu is always greyed out. Like you say - probably a proprietary startup/handshake that the Nano is expecting :-(

from softrf.

Gentlemen, I use my trusty old CAI302 vario/logger for years and pretty much happy with it.
And I don't have neither FLARM nor Nano3 readily available here. Thus I have no need (nor wish) for myself to make SoftRF more friendly to the Nano.
On the other side, I consider that this feature could be useful for some SoftRF builders in the future.

So my suggestion for you is to either:

• take part and responsibility of developing this feature on yourself. Fork a copy of my repository and do your stuff there. When (if) the feature will be ready to integrate into mainstream - we will dicsuss on how to do it in the best way, or ;
• if you are unable - please, close this ticket.

from softrf.

from softrf.

Ok, let me know if you will succeed - I will reopen and assign this ticket to you.

Resolution: unable to reproduce.

from softrf.

Hi
Pete how are you physically connecting your SoftRF to the Nano 3 - I’m interested in trying to get this going. Have you spliced a micro USB to a mini USB to facilitate the connection?

Cheers

from softrf.

from softrf.

Checksum issue #24 remedied this. The SoftRF now enables the Flarm menu in the Nano.

I suppose that this could be an accumulated effect of 84668a7 and #24.

from softrf.

Hi Pete

OK - will take a look and get an esp32 rigged up in a breakout for testing

from softrf.

from softrf.

Hi Linar, The only suggested additions to the D1090helper might be;

        snprintf((char *) &Serial_Load, 21, "$PFLAC,A,ID,%x*", ThisAircraft.addr & 0xFFFFFF ); 
        Flarm_Export(); //Append checksum and print
        snprintf((char *) &Serial_Load, 21, "$PFLAC,A,ACFT,%d*", ThisAircraft.aircraft_type); 
        Flarm_Export(); //Append checksum and print

Apologies if my code frustrates, I'm a little new to this.

Pete

from softrf.

Pete,
it does not work this way.

At first, you should create a fork of the SoftRF repository on GitHub. Like all these guys did:
https://github.com/lyusupov/SoftRF/network/members

At second, you should alter the code in your repo as long as you want and commit changes into it with appropriate comments.
Build the code from your repo and test it on your hardware until you think it is in perfect state.

Then go back into this thread and I'll tell you what to do next.

from softrf.

$PFLAC is a part of 2-way configuration mechanism. Nano sends $PFLAC,R,.. request and expects to receive $PFLAC,A,... "answer" (FLARM FTD-12 PDF, Section 7.15).

SoftRF is using WebUI for configuration - there is no need to have an old-style UART-based control port.
"NMEA channel" is one-way only. From SoftRF to target device. No reverse direction.
In ESP8266-based SoftRF there are no spare pins to implement this back channel.
In ESP32-based SoftRF there are some, but no any firmware support for this. And no any plans to add it.

If your Nano needs to get a response on it's $PFLAC,R,.. request - you may consider to
put a separate 3.3V friendly Arduino board in the middle. You can program it to do a mix:

• give appropriate $PFLAC,A responses on the $PFLAC,R requests ;
• transparently forward all NMEA traffic from SoftRF to your Nano.

Pros:

• the sketch for the Arduino-in-the-middle should be pretty much simple ;
• with this approach, there is no need to change anything in the SoftRF hardware and firmware.

from softrf.

from softrf.

from softrf.

SoftRF uses 9600 baud rate for input (BN-880 , T-Beam and many other module's factory default) and 38400 baud rate for output (maximum of that HC-05 can handle).

SoftRF on ESP8266 has support for 2 sources on GNSS NMEA data input:

• SOC_GPIO_PIN_SWSER_RX (9600 baud)
• NodeMCU's RXD0 pin (38400 baud)

SoftRF on ESP32 has support for 3 sources on GNSS NMEA data input:

• SOC_GPIO_PIN_GNSS_RX (9600 baud)
• ESP32's U0RXD pin (38400 baud)
• built-in Bluetooth

2nd source (in both cases) has a h/w conflict with built-in CP210X chip. For details, read this.
It is known to work Ok, but applies stress load on all electrical components involved.
That is why it is not recommended for general use.
(2nd source is mostly designed to receive NMEA GNSS feed from external, "USB host" capable equipment, such as PC, Raspberry Pi, Kobo, Android smartphone/tablet).

SoftRF does not apply any filters (except checksum) while forwarding of GNSS NMEA sentences from input to output.
GxRMC and GxGGA sentencies are in use for internal SoftRF firmware operation. All others are just transparently being forwarded with no effect on SoftRF's firmware behavior.

from softrf.

Hi, The nano ‘USB’ port also acts as a serial port too. RX & TX @ 3.3v. I’m sure you’re aware that there are four wires. + & - are obvious. I soldered the mini to the physical Rx & Tx of the ESP32 I’m using. Would be good to collaborate here.

Sorry for offtopic, but I could not find another thread.

@PeteMilligan99 do you have any pinout sketch how you connect your Nano to PC using FT232, I do not want to burn out my nano 4 :)

from softrf.

https://gitter.im/lyusupov/SoftRF

from softrf.