-
- Notifications
You must be signed in to change notification settings - Fork 155
Made rssi and datetime bg function portable to crsf and sport #81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Made rssi and datetime bg function portable to crsf and sport #81
Conversation
src/SCRIPTS/BF/background.lua Outdated
local newSensorValue = getValue(sensorId) | ||
| ||
if not timeIsSet and type(newSensorValue) == "number" and newSensorValue > 0 then | ||
if not timeIsSet and protocol.push() then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't work (at least on SmartPort), since the telemetry connection is never actually lost when the flight controller is rebooted but the RX isn't power cycled.
18ef9bc
to 347e31a
Compare Looks like we're good now! |
@raphaelcoeffic: Why was this merged? It looks like you did not even test if what I remarked in my review is fixed, since it clearly is not. |
It has been, as it seems, and the new code was exactly what you were asking for. The link says "Show outdated" / "Hide outdated". It now uses a different sensor for each prot implementation instead of the empty push(). |
Huh? What are you talking about? Do you even read review comments before you click merge? |
@mikeller of course!!! |
So why did you merge it then without even checking if the 'This doesn't work' comment that I made did still apply? |
@mikeller I checked the updated code. It's now using the proper sensors. Look for yourself! |
@raphaelcoeffic: Please read my comment above: It does not work. You merged code that is still broken in a way that is reproducible by my description above. Please don't do that. |
@mikeller please accept my apologies, I was sure I had understood the issue, which I clearly didn't. |
All good now, we've discussed it, let's move on and try to improve processes for this repository in the future. |
@codecae ok, so you do see the packets being sent, that's good. But the time is still not set, or is it? |
That was next :) |
I'm just supplying some artifacts depicting output being pushed to the telem buffer and hitting the rx |
@codecae wait a sec: for the SPORT MSP_SET_RTC, don't you see the second packet? There should be a second one. The second one you posted is the reply from the FC, not request - part2. |
ok, so the second packet IS there, that good as well. |
wait.. I may have grabbed the wrong stuff.. there's something not right about the smartport one.. redoing it now... the time between 0x1B and 0x10 seem suspicious. |
Ok those look better now. I don't see that it's updating, though. Will need to run a debugger on the bf side, because it looks like the data is being sent. |
works for smartport |
Same issue here... I'm using HEAD of master (on the BF side), and the time is NOT set, whereby I can see the requests as well. |
wait.. it works.. I just checked it. |
looks like a timing thing... maybe need to use a different sensor. If I power up the fc, then the radio, it works. Other way around, it does not. |
I removed the telemetry script to test with a one-time only, and I cannot get it to work....
|
it works sporadically. trying to find a way to reproduce reliably. I've seen the clock get set on both formats. something about the timing is off. |
where? on the BF side? |
Used protocol code to make the rssi and datetime updates protocol agnostic.