Jeti 1464

[michel49]

Hi all,

Last time I used a Jeti FW (don't understand which one) it works well; when I use the last one -1464- I get only two lines of strange symbols...

What happens ?

[bertrand35]

A bug... Do you see something like that?
Did you already install a Jeti version of open9x? Or of er9x?
Bertrand.

[michel49]

Exact,

Of course I already used an old FW for ER9X which works well; I believe it would be worth to
improve the display since Jeti never give a screen which can display four parameters
on the same screen ( I own the 4 input hub).

Do you think the bug will be fixed in the future ?

Regards,

Michel

[bertrand35]

I fixed a little bug, but nothing really interesting. Would you try the last version of er9x and tell-me if it is ok for you?
Bertrand.

[michel49]

Which one is the last ?

Companion don't give me an auto update for Jeti FW.

[Rob Thomson]

I wonder sometimes...

Seems to me that all the telemetry systems out their just to some degree support similar inputs and outputs to the frsky system?

So.. Why do we have a jeti version of the firmware? Surely we should have one telemetry feature set.. and just a driver option to translate the different protocol to a set standard?

Sent from my Nexus 7 using Tapatalk 2

[michel49]

Wonderful idea....it would be great not to have to flash to switch from FrSky to Jeti...

Regards

MP

[bertrand35]

Was the original bug fixed in last release?
Bertrand.

[Romolo]

I wonder sometimes...

Seems to me that all the telemetry systems out their just to some degree support similar inputs and outputs to the frsky system?

So.. Why do we have a jeti version of the firmware? Surely we should have one telemetry feature set.. and just a driver option to translate the different protocol to a set standard?

Sent from my Nexus 7 using Tapatalk 2

Good idea but unfeasible at least on stock board...
Flash is your enemy,,,,

[Rob Thomson]

Could be a simple compile time option. Much as you have now... But just means all the existing telemetry logic that is coded just works?

Sent from my Nexus 7 using Tapatalk 2

[michel49]

Remember the Jeti telemetry is a bit better than the FrSky....there is no RPM/brushless sensor from FrSky...

I assume the poor old TH9X µC is very close to its limit now...

[Kilrah]

Yeah but RPM is still RPM, the sensor doesn't matter. What Rob suggests that the processing/logic/display code could be common to all telemetry systems, only the protocol decoding being different depending on the hardware. Sounds like a good idea.

[Rob Thomson]

What it would do is mean that systems like jeti would get a better over-all support

And of course.. in the future if someone wanted to use say.. a telemetry system by Corona. Well it would also be one hell of a lot easier to integrate!

[michel49]

Kilrah, tu n'as pas à mesurer de RPM/EDF ?

Bien sûr qu'un systeme unique serait preferable...

[Kilrah]

Non, mais pour la proposition de Rob ça change rien. 100 RPM c'est 100 RPM, que ce soit un EDF, une hélice de bateau ou un rotor d'hélico, et que ce soit mesuré en optique, en magnétique ou en électrique. Le capteur est peut-être différent, la manière d'amener la mesure à destination aussi (frsky, jeti, xbee,...), mais au final on finit par afficher juste une valeur sur un écran.

On a au début eu des versions jeti, frsky, ardupilot, nmea assez basiques et toutes différentes. Frsky étant très répandu cette branche s'est beaucoup développée (écrans personnalisables, utilisation des valeurs dans les inters personnalisés,...) et offre maintenant beaucoup plus que les autres. Par contre la majorité du code n'a rien à voir avec frsky spécifiquement, c'est uniquement de l'affichage et de la configuration.

D'où l'idée de rendre cette partie affichage un peu plus générique et commune à tous les systèmes de télémétrie. On a une variable "RPM" qui se fait afficher où on veut si on le veut. Ensuite, on ne change plus que la couche du dessous pour s'adapter au matériel. Si on utilise du frsky, on décode le protocole frsky, on récupère la valeur de RPM et on la passe dans cette variable pour affichage. Si on a un capteur jeti, on décode le protocole jeti, on récupère la valeur de RPM et on la passe dans cette variable pour affichage. Ca revient au même.

Cette amélioration est clairement un passage à faire prochainement

[bertrand35]

I don't understand your charabia But I do agree... Just missing time!
Bertrand.

[Rob Thomson]

No doubt it will be done at some point. Plenty of other things to do to keep us all busy.

But long term - this would make the whole telemetry system very versatile - and open it up to others who are not so frsky biased

[bertrand35]

One thing that I miss: this JETI telemetry system, I have reviewed the jeti.cpp, but ... it doesn't seem to have anything relative to fields like RPM, Altitude, GPS position like we have on FrSky system. We just display 2 lines "JetiBuffer" on screen (so it's text!). What are they supposted to be???
Bertrand.

[Rob Thomson]

I dont understand the german.. but you can see what you get on this url?

http://www.youtube.com/watch?v=KGUOtRLTx44

[Kilrah]

Hmm, looks like the radio just serves as a terminal... sends keypresses to the module, which runs its own menu system, and sends 2 lines of text back.

So yeah, no uniformization for Jeti...

[bertrand35]

In my opinion the menu logic is inside the receiver. At least it is not inside the 9x!
Bertrand.

[Rob Thomson]

Rather rubbish if that is the case!

[Kilrah]

Well, to their defense, they were the first to come up with an R/C system with integrated telemetry, about 3 years ago!

As they were not manufacturing any radio, only modules and receivers, it didn't necessarily make much sense giving out binary data. Don't think Futaba or so would have implemented a display system!
And having just a "passive" input/display box with a 2x16 LCD and 4 buttons that never needs a firmware upgrade is pretty convenient from a user point of view...

[Rob Thomson]

True.. but a little short sighted when you consider where telemetry is heading; and what we are all doing with it!

[Kilrah]

What WE are doing with it, yep - I don't know of another consumer system where the integrated telemetry feedback can actually act on the inputs again yet!
It's the 9x being in advance, they were just right at the time

[bertrand35]

And my original issue? Do we still have the same strange chars on screen Michel? Did you try the latest versions of er9x? We have exactly the same code in both projects!
Bertrand.

[michel49]

Hi Bertrand,

I just flashed the last ER9x (777) Jeti version and I just get "JETI" on the upper left side on the screen, very strange; I can't remember -long time ago- which ER9X FW worked well but I'm sure it worked ! and it gave the SAME display as the original (ugly) Jeti screen.
That is the way I think it is possible to display the Jeti datas the same way as FrSky.
Some years ago Jeti give promises (politician...) to make a real terminal in order to sell his Duplex system but he never give it available and lost his consumers...

[manu]

I have a er9x r736 running with jeti.
As I know the hole logic sits in the rf module, the tx just acts as a JETI Box, transfers the date to the display.
Altough I changed to FrsSky, for me jeti was the starter to get into the 9x story, so please leave it alive.
I have the hardware, please let me know If I can help testing something.
manu

[Kilrah]

Cool, I think as a start it would be nice if you could test the jeti versions of the current revisions of both er9x and open9x with your hardware, to see if nothing has been broken! Jeti users seem very scarce, so there's little feedback...

[manu]

ok. I tried both er9x and open9x:
er9x-jeti.r777:
There is a kind of telemtry screen but without usable data. I doubt that jeti can provide the data the same as frksy does.
open9x-stock-jeti-en-r1464:
Pretty the same telemetry screen as bertrand posted: viewtopic.php?f=45&t=1782&p=28675#p25758
In the upper left corner I only see "16" instead of "JETI".
As I said, er9x-jeti.r736 just runs as expected.
regards
manu