Open williajgr opened 6 months ago
i am getting a 15K jet ready i certainly don't trust ethos to fly it any idea when things will stable out or should i just go to jetti???? since your big update everything has beel scrambled and very slow responces to issues if any.
displays on the screen correct but stores all wrong
Please provide some details and logs showing the issue.
Also some details on what exact equipment you are using.
Yes. I need more information to understand what is wrong:
sending an image of a cvs file. looks like it is messing up on storing the hour correctly.
Can you attach that CSV file?
You have chosen to adjust the radio clock from the GPS data and the GPS has some latency?
By the way, what is completely broken?
if you look at any of the graphs with the hours messed up they look really crazy. I will send a more complicated one. td-18 receiver. gps frsky pressure gauge altimeter 2 turbine connections notice all the missing data at the start gear pressure crazy numbers tx consumption F15-2024-04-10-19-08-05.csv
turbin sensors from Lior Zahavi
~~It seems to me that the problem comes from the GPS which is constantly adjusting the radio clock. If I am not mistaken this problem is there since several years in all firmware releases.~~
The problem comes from the way the ms are written in the log file. The fix will be ready tomorrow
The missing numbers on the top of your CSV ... perhaps because your model was not powered?
PRESURE GEAR(PSI) => what is this sensor?
"tx consumption" => what is the column? I
The "ms" part of the hour is not correct. I will fix it tomorrow
I never changed anything on the radio. One of the updates must have changed it. I will have to figure out how to undo that. I assume in system?Sent from my iPhoneOn Apr 18, 2024, at 12:09 PM, Bertrand Songis @ FrSky @.***> wrote: The missing numbers on the top of your CSV ... perhaps because your model was not powered?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
The ms part of the hour bug is there since > 3 years. I have just checked.
gear pressure is a custom sensor derived from the frsky pressure sensor which reads 14.7 lbs too much. didn't do any adds except the source. never had the hour thing bother me until i put 1.54 on.
rpm isn't reading correct ether don't have any idea what it is storing. it is displayed correctly on the screen. seems like some of custom and diy sensors have a problem and some don't
The time returned by the GPS seems jumping, how is it possible?
Then each time the GPS hour jumps, the radio hour will jump too!
Perhaps you have recently enabled the "Auto adjust from GPS"?
GPS question ? Can one get a bread crumb trail on the gps mapSent from my iPhone
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
the auto adjust from gps was set to on. i just turned it off and tried it again it worked but it was a bad test as it is rainy here and never got the gps to work. it is the advanced frsky gps maybe it is getting weak signals sometimes one of the cvs's is a rc car.
I hope the rain will stop soon then. This GPS clock issue is not normal. I would need you check:
1) that indeed the GPS clock is jumping very often, as it does in your logfile 2) if you confirm the issue above, what have you configured as Time zone? 3) if you change this time zone and choose GMT+00:00, the clock will be bad, ok, but is it jumping? if the answer to this question is NO, then the bug is in Ethos in the UTC => local clock calculations
For now I cannot see anything related to the update to 1.5.4
never touched that number as i didn't know that option was available.. I just turned it off and set the time zone to -4 dlst new york
Wait, it was set to 0 before (when your logfiles were recorded)? Then it would seem more a GPS issue ...
i hate the answer i have. not sure if it was 0 or-1
when i get a good signal would you like ne to turn the automatic back on?
Yes please try when you can: 1) with timezone = New York => OK / KO 2) with timezone = 0 => OK / KO
OK : time seems perfect KO : time jumps as it does in your logfile
will do
when i set the auto off i noticed the clock was wrong and had to reset the minutes. shouldn't the minutes be right from the auto?
We have 2 problems in this issue:
1) the "ms" part of the clock in your logs, it is reset, but not properly, each time the clock is adjusted:
=> this bug doesn't need more tests, the fix is ready for the next nightlies, and 1.5.7
2) the GPS clock which is jumping I don't understand where is the issue (either it's the sensor itself, I will have to forward the problem to the right person, or it's Ethos which is messing with time zones, I doubt, but it needs to be checked)
What is interesting for me is to know if the GPS jumps:
COuld the GPS clock jumping be related to #3760 ?
ok got to try everything out. auto off . GPS clock didn't jump around but it was the wrong time. clock set to 24hr mode. radio gps am 9:25:49 9:24:59 date time Pm 4 20 16:08:28.3 4-21 1:07:29
Sorry but I am french, and I don't understand your last message.
I move this issue to the next milestone, I have not enough information for 1.5.7
Bert, I think I can make some sense of Will's post on April 20th: The first time am9:25:49 is that of the radio itself, the other is form the GPS, which is "delayed" related to the radio time. This is something very annoying because the GPS data (like speed, altitude, etc) is useless for any action or warning generation. Anyhow, about the other line, I cannot explain the Pm but it seems to me that 4 20 and 4-21 indicate the dates (April 20 and 21) logged from the transmitter and GPS respectively. Now, the times do not have any relation whatsoever.
ok got to try everything out. auto off . GPS clock didn't jump around but it was the wrong time. clock set to 24hr mode. Sorry about the confusion . Get hub takes all of the spaces out and jamms everything together. Test one in the morning -----radio time-------------gps time am ----9:25:49 ---------------9:24:59 Test two in the afternoon ---------date-----------time---------GPS-- date----------time PM----4 20-24------ 16:08:28.3-------- ---4-21-24-----1:07:29
any idea why a calculated pressure changes PSI to a crazy huge number
It’s probably calculating in pascals
Am is in the morning pm is in the afternoon Sent from my iPhoneOn Apr 22, 2024, at 8:28 AM, mawzthefinn @.***> wrote: It’s probably calculating in pascals
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
I don't know if it's me, my english level, or github ... but the discussion in this issue is difficult to follow!
Am is in the morning pm is in the afternoon Sent from my iPhoneOn Apr 22, 2024, at 8:28 AM, mawzthefinn @.> wrote: It’s probably calculating in pascals —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.>
Example this message: I understand that it's calculating in Pascals because AM is in the morning and PM is in the afternoon
ok got to try everything out. auto off . GPS clock didn't jump around but it was the wrong time. clock set to 24hr mode. Sorry about the confusion . Get hub takes all of the spaces out and jamms everything together. Test one in the morning -----radio time-------------gps time am ----9:25:49 ---------------9:24:59 Test two in the afternoon ---------date-----------time---------GPS-- date----------time PM----4 20-24------ 16:08:28.3-------- ---4-21-24-----1:07:29
May I suggest you do a longer test, just to see if the GPS jumps again? With the logs enabled to be sure ...
why do you think it is calculating in pascals? shouldn't be
why do you think it is calculating in pascals? shouldn't be
The unusually large numbers. Pascals are a tiny unit and any case where something happens in pascals and doesn't get converted back would result in absurdly large values
I told the sensor to use psi so why is it using pascals? Sent from my iPhoneOn Apr 23, 2024, at 7:56 PM, mawzthefinn @.***> wrote:
why do you think it is calculating in pascals? shouldn't be
The unusually large numbers. Pascals are a tiny unit and any case where something happens in pascals and doesn't get converted back would result in absurdly large values
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
why do you think it is calculating in pascals? shouldn't be ROVER-TEST-2024-04-23-16-54-17.csv looks like the GPS is jumping around and even the date is wrong
Indeed, the GPS seems totally wrong!
Would you show a screenshot of the configuration for the sensor "PRESURE GEAR"?
I don't get half of the telemetry numbers and most of them are wrong. what level of firmware works for telemetry? 5.1???? i think it got messed up between 5.1 and 5.4 i don't dare try 5.6 This is crazy