Transition to standalone application.

[mikeller]

I have a way of doing it (using NW.js, building on code that's been tested in the Betaflight configurator).

But I need maintainer access to be able to debug things like automatic checking for new releases through the GitHub API. @kh4, @DTFUHF: Can I please get maintainer access for this repository?

[cTn-dev]

I will step in and take care of standalone builds when it becomes time critical, the app store is still showing all the packaged apps and i haven't received any info from the dev support regarding exact date when the support will be dropped.

[mikeller]

@cTn-dev: The notifications went out in 2016, and then again at the beginning of this year. The official post is here: https://blog.chromium.org/2016/08/from-chrome-apps-to-web.html

So the clock is ticking, with potentially as little as 27 days left...

What are your plans for producing the standalone versions? What framework are you going to use? How are you going to distribute them, and how will users know if there is a new version available? If you share your plans maybe I can help.

[cTn-dev]

Oh, i got that notification (i meant that they didn't point out a specific date).
That's why i found the
"In the second half of 2017, the Chrome Web Store will no longer show Chrome apps on Windows, Mac, and Linux, but will continue to surface extensions and themes."
rather odd since we are near the end of 2017 and i still haven't received any more info and the apps are still visible on the store for some reason.

I will most likely use NW.js as well, as i have the most experience with it.
Sources will be available here + the extra NW.js binaries for each platform.
Each build will be available to download from the repo and there will links on the http://openlrsng.org/

I should be able to cover windows/linux testing + i am sure @kh4 can run a few tests on linux if needed.
The OSX version will need some testing since i don't have access to machine that runs native OSX.

I guess most users will know about the update from IRC and other channels.
As of right now i have no idea what will happen to the already installed apps (will they get disabled? automatically removed?), the info i received so far doesn't cover that.

This is why i am still waiting for more info/what will happen to the apps on the store before i commit into any major changes.

[mikeller]

@cTn-dev: Re more info, I am not sure that any will be forthcoming (or else they would surely have sent a 'impending sunset' notice by now. So instead of waiting until the Chrome Web Store is shut, I think we should rather try and get a version that enables a smooth transition to the standalone version out to users while the Chrome Web Store's auto-update still works.

We recently converted the Betaflight configurator to NW.js, and, considering the two apps share common ancestry, it should be easy to port the changes that were made there into the openLRSng configurator. I am happy to help with this.

Re updating and update notifications, I think it is not very user friendly if we expect the users of the app to regularly go and check in on a website (or even hang out on IRC) to find out if the app they are using is outdated. What we are will be doing in Betaflight is to use the GitHub API to query for new releases, and notify users inside the app when a new version has been released, complete with a link to the download page for the release. What do you think about adding this to openLRSng configurator? (I got most of this ready already, but I need to be able to do some RC releases to test this, that's why I've asked for access to be able to do configurator releases.)

Ideally we'll get the next version of the configurator that integrates this update check released to users through the Chrome Web Store, so that they will get a notification that asks them to install the standalone version when the time comes for the first update after the Chrome Web Store...

And while we're at it, I'd also like to switch from having the firmware 'baked in' the configurator to using the same GitHub API to query for, and offer to download, the latest firmware.

Thoughts?

[kh4]

So @mikeller now has owner access, use it well.

[mikeller]

Thanks @kh4. Just when I started to run out of things to do for Betaflight. ;-)
The plan is to do something similar to what we've done for Betaflight, and release a few release candidates, so kinks can be worked out, and the update notification system (pulling release info from GitHub) can be tested.

[KnuckleUpFPV]

@mikeller let me know what I can do to help test. I was getting worried I would lose my chrome configurator soon. I fly daily with openlrs and would love to continue to do so. I have it on a fixed wing as well as a few miniquads.

[mikeller]

Thanks for you offer, @KnuckleUpFPV. I'll be making some changes to allow downloading of firmware images from GitHub (instead of baking them into the configurator) soon, and getting some testing for this, and for the standalone configurator that is to follow will be helpful.

[KnuckleUpFPV]

I have flytron, hawkeye, orangerx, wolfbox, and a few homemade modules I can test with on receiver side. On transmit side , i have orangerx, wolfbox, and a homemade tx. Looking forward to this. With the long range craze going on, its likely tp bring more pilots to openlrs because its affordable and works

[mikeller]

I think it's definitely worth keeping it alive, and with the multiprotocol support it gets a whole lot more user friendly as well.

[KnuckleUpFPV]

I need to try it with the multi support. Do you have a link to the firmware I need? I can flash my modules with arduino. Thats how I was doing it before I learned about the configurator. I was actually so worried that I picked up a book on how to write code. Im pretty good with self teaching. Im still going to learn all that I can in hope that I may be of help someday.

[mikeller]

You can use the binaries from here: https://github.com/openLRSng/openLRSng/releases/tag/3.9.0-rc1
You'll also need to download the latest configurator from GitHub, unzip it, and install it in Chrome locally.

[KnuckleUpFPV]

Thank you. Ill see if I can get this worked out tonight when I get off.

[KnuckleUpFPV]

I flashed the new firmware and installed the new configurator. No luck. I tried opentx 2.2 and 2.2.1. Neither will work on multi with the wolfbox. I set it to multi in configurator.

[mikeller]

What firmware are you using on your transmitter (OpenTx / ersky9x / ...)? You'll have to select 'openLRSng' / 'olrs' as the protocol for it to work.

[KnuckleUpFPV]

Tried opentx 2.2 and 2.2.1 and selected olrs. Its not communicating. Still works set as ppm though.

[mikeller]

Ok. Have you adjusted the wiring so that the 'PPM out' pin of the TX is connected to the serial RX of the radio module, and the 'telemetry in' pin is connected to the serial TX of the module?

[KnuckleUpFPV]

That I did not do. Was unaware of this modification. The wolfbox has an s port jumper on the back. In order to connect to receiver the jumper has to be on s port or it won't connect.

[mikeller]

I suspect said jumper will only affect the telemetry side of things (module => TX). Looking at the bad quality images for the wolfbox that are available online, there are serial RX / TX pins available on the back of it (the same ones you are using for firmware updates). You should be able to use these and fashion a cable to connect them to the external serial pins of the tx (over cross that is).

[KnuckleUpFPV]

Any way I can get some clean images to you? If the jumper isnt in place it will not communicate with the tx. I have an orangerx module I can try this with as well. I have the telemetry mod done on the orangerx. Hooks tx to rf pin. And a few other connections. I feel like this may get in the way of this mod.

[mikeller]

The 'tx to rf pin' is half of what is needed, the part that I described as 'the telemetry in pin is connected to the serial TX of the module'.

For multiprotocol to work, you'll also have a connection from the TX serial out (which shares the pin with PPM out) to the modules serial in, since multiprotocol sends data through serial instead of PPM, and the module can only receive serial data fast enough on the hardware serial port.

[jimmycapizzi]

Ok, so I got the DTF 1w box transmitter. Does the tx signal have to be inverted for this to work? Is there gonna be some information on the multi protocol in the wiki? Would like to get this working with my taranis q x7

[KnuckleUpFPV]

Ok i think im tracking. Ppm pin to rx pin on serial side and tx pin on serial side to rf pin.

[KnuckleUpFPV]

Jimmy I'm using a qx7 as well. I will let you know if I figure it out. I dont know if I have the wiring correct for the mod though.

[jimmycapizzi]

Thanks alot, I'm subscribed!

[mikeller]

@jimmycapizzi: The TX (telemetry) signal from the module does have to be inverted if you are using a FrSky / Taranis TX. Turnigy 9XR Pro has a switchable inverter on the telemetry pin. I will be adding information to the wiki at some point, but at the moment I am flat out to get the standalone configurator going before the deadline imposed by Google.

(Additionally, I don't have access to most of the hardware, so I'll have to rely on help from the community to get the hardware specific parts documented.)

[KnuckleUpFPV]

@mikeller if you give me somewhere to send you pics I can email you high res photos. Or you can email me. [email protected]. i will delete this after I hear from you. Unless you want to start an rcgroup post. Then we can share images there. The old openlrs thread is incredibly long. Im happy to help in any way possible. Am I correct on my wiring? Ppm to rx on serial and tx on serial to rf pin?

[KnuckleUpFPV]

@jimmycapizzi the rx to ppm pin and tx to rf pin did not work. So I'm lost on where to go from here.

[jimmycapizzi]

Thanks for the help guys, we will get it worked out.

[mikeller]

@KnuckleUpFPV: My preference would be to use some sort of chat / forum to have these discussion. I am not a fan of the IRC (for it's lack of decent history / search / file integration or any other thing that was invented after 1980). How about slack? It seems to be working reasonably well for other projects I am involved in.

I have never actually tested with FrSky / Taranis hardware. But knowing them, one possibility is that it might require an inverter between the TX and the module (just a simple transistor should do at a pinch).

Also, in order to make debugging this easier: Multiprotocol is designed to work fine with just the PPM pin => serial RX connection, and no feedback from the module (It supports feedback, but openLRSng does not yet implement it). So it probably makes sense to first focus on that connection, and get the module to a point where it's picking up a valid signal (remember to select MULTI in the 'serial port speed` dropdown in the configurator for the config that is selected when the module starts up), and can be made to go into binding mode by selecting [Bind] on the TX.
Once this is all working, telemetry feedback can be addressed in the next step.

[KnuckleUpFPV]

We can use slack if you like. I have a transistor mod in the orangerx to get the telemetry to wish i could post a photo here. I've removed the resistor at r2 to seperate the rf pin for the telemetry mod. I was thinking this is why it didn't work. So grabbed a second module and took rf to tx and rx to ppm. No luck. Added a 1k resistor to rx so configurator would still work. And still nothing. I have plenty of bits and bobs in a bunch of different sizes. I can try just about anything. Just need guidance on what to do.

[mikeller]

This is what will work with 9XR Pro and should work with Taranis (will try to confirm Taranis tomorrow):

(Not sure if removing R3 is absolutely necessary, if the trace goes only to the MCU pin, which will be high impedance if it isn't used, leaving it in should be fine.)

Re slack, come find me in the Betaflight slack, registration is at http://www.betaflight.ch/ .

[marcdornan]

Hi Mike. Saw on RCGroups that you are sprucing up openlrs ng. Great news. Do you think we should fire up a new thread on RCGroups so people know about this?

[mikeller]

Hi @marcdornan. 'Sprucing up' is a big word (two actually). What I am trying to do right now is to keep openLRSng (or at least the configurator) from going under when Google pulls the plug on non-Chromebook web store apps.

Feel free to bring it up on RCGroups, I am not really active there. I hope to be able to provide all of the information that is needed for users here on GitHub, but spreading the word through RCGroups, and reaching more users, is certainly a good thing.

[fiveangle]

I can try this too, but I’ve not done the hardware mod, and it definitely looks quite different on the Hawkeye/DTF 1 W Deluxe JR module:

EDIT: Thought I vaguely remembered some jumper settings inside, and dug the manual out of the bowels of my dropbox and it has this to say:

Invert TX:ON|OFF (Default ON)
This controls if the serial TX line is inverted or not. Should be set to "ON" for Frsky Taranis to allow telemetry operation. May need to be set depending on Telemetry mods on your TX unit.

INVERT RX:ON|OFF (Default ON)
This controls if the serial RX line is inverted. May need to be set depending on Telemetry mods on your TX unit.

PPM Type:PPM|SERIAL (Default PPM)
This controls where the 'pin 1' from the TX is connected to. For transmitters outputting PPM set to PPM. For SUMD/SBUS/Spektrum serial formats set to SERIAL, notably INVERT RX should be set too (SBUS:ON, SUMD/Spektrum OFF)

So it looks like just toggling the PPM Type jumper will take care of all that's necessary to get MULTI working. If it doesn't work, I'll try toggling the inversion. Stay tuned…

-=dave

[KnuckleUpFPV]

You can most likely set your module to serial with jumper and it should work. Wolfbox and orangerx needed the mod of single wire with 1k resistor from ppm pin to rx pin

[mikeller]

@fiveangle:

So it looks like just toggling the PPM Type jumper will take care of all that's necessary to get MULTI working. If it doesn't work, I'll try toggling the inversion. Stay tuned…

As for MULTI alone: Yes. If using a taranis, Invert TX will also have to be set to on for telemetry to be possible.

[KnuckleUpFPV]

What's the baud rate for frsky telemetry? Im still just getting normal receiver telemetry and nothing from the fc. I have inav lua script and its only picking up rssi. I haven't tried any baudrates yet because ive been in bed sick for 3 days. I dont care if I cant get the full telemetry but it would be nice to have for gps coordinates in case I lose video and sd card corrupts or fills up before something bad happens.

[mikeller]

Same as with other Multiprotocol modules, the baudrate for telemetry is the same as the baudrate of the TX -> module connection, 100000, 8e2, since it's designed to be using the same UART. The TX should adjust this automatically as soon as Multiprotocol is selected.

[KnuckleUpFPV]

Im sorry i meant on the receiver side. The fc isnt sending telemetry back to the transmitter. Just the normal rssi and two analogs. I will try to reflash tx and rx with rc2 and see if any different baudrate will work on the fc. Regardless im extremely happy. No latency and the rssi is outstanding. I think once I'm feeling better I may try the experimental data speeds and see what the range is like. Going down to just over 7ms and still be able to fly out a mile or two would be fantastic.

[mikeller]

@KnuckleUpFPV: Same deal - since there's only one UART in the RX, the speeds have to be the same. If you're using Betaflight, this will be taken care of by the firmware, and your telemetry speed ignored.

[raul-ortega]

I created a new pull request adding the package.js file to build the stand alone app with nw.js:

#38

To test the result take a look at:

[If you would like to test the result, I cloned the respository and bild the win32 version:

https://github.com/raul-ortega/openLRSng-configurator/releases/tag/3.8.8](If you would like to test the result, I cloned the respository and bild the win32 version:

https://github.com/raul-ortega/openLRSng-configurator/releases/tag/3.8.8)