Skip to content

Conversation

codecae
Copy link
Member

@codecae codecae commented Nov 15, 2017

Used protocol code to make the rssi and datetime updates protocol agnostic.

@codecae codecae requested a review from mikeller November 15, 2017 06:20
local newSensorValue = getValue(sensorId)

if not timeIsSet and type(newSensorValue) == "number" and newSensorValue > 0 then
if not timeIsSet and protocol.push() then
Copy link
Member

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.

@codecae codecae force-pushed the crsf_smartport_rssi_datetime branch from 18ef9bc to 347e31a Compare November 15, 2017 07:08
@raphaelcoeffic
Copy link
Member

Looks like we're good now!

@raphaelcoeffic raphaelcoeffic merged commit 9c2ccfd into betaflight:master Nov 15, 2017
@mikeller
Copy link
Member

@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.

@raphaelcoeffic
Copy link
Member

raphaelcoeffic commented Nov 15, 2017

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().

@mikeller
Copy link
Member

Huh? What are you talking about? Do you even read review comments before you click merge?

@raphaelcoeffic
Copy link
Member

@mikeller of course!!!

@mikeller
Copy link
Member

mikeller commented Nov 15, 2017

So why did you merge it then without even checking if the 'This doesn't work' comment that I made did still apply?

@raphaelcoeffic
Copy link
Member

@mikeller I checked the updated code. It's now using the proper sensors. Look for yourself!

@mikeller
Copy link
Member

@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.

@raphaelcoeffic
Copy link
Member

@mikeller please accept my apologies, I was sure I had understood the issue, which I clearly didn't.

@mikeller
Copy link
Member

All good now, we've discussed it, let's move on and try to improve processes for this repository in the future.

@codecae
Copy link
Member Author

codecae commented Nov 16, 2017

Crossfire MSP_SET_RTC:
image
image

Crossfire MSP_TX_INFO:
image

@codecae
Copy link
Member Author

codecae commented Nov 16, 2017

SmartPort MSP_SET_RTC:
image
image

Smartport MSP_TX_INFO:
image

@raphaelcoeffic
Copy link
Member

@codecae ok, so you do see the packets being sent, that's good. But the time is still not set, or is it?

@codecae
Copy link
Member Author

codecae commented Nov 16, 2017

That was next :)

@codecae
Copy link
Member Author

codecae commented Nov 16, 2017

I'm just supplying some artifacts depicting output being pushed to the telem buffer and hitting the rx

@raphaelcoeffic
Copy link
Member

@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.

@raphaelcoeffic
Copy link
Member

ok, so the second packet IS there, that good as well.

@codecae
Copy link
Member Author

codecae commented Nov 16, 2017

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.

@codecae
Copy link
Member Author

codecae commented Nov 16, 2017

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.

@codecae
Copy link
Member Author

codecae commented Nov 16, 2017

works for smartport

@raphaelcoeffic
Copy link
Member

raphaelcoeffic commented Nov 16, 2017

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.

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.

@codecae
Copy link
Member Author

codecae commented Nov 16, 2017

wait.. it works.. I just checked it.

@codecae
Copy link
Member Author

codecae commented Nov 16, 2017

Crossfire:
image

@codecae
Copy link
Member Author

codecae commented Nov 16, 2017

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.

@raphaelcoeffic
Copy link
Member

I removed the telemetry script to test with a one-time only, and I cannot get it to work....

SCRIPT_HOME = "/SCRIPTS/BF" protocol = assert(loadScript(SCRIPT_HOME.."/protocols.lua"))() radio = assert(loadScript(SCRIPT_HOME.."/radios.lua"))() assert(loadScript(radio.preLoad))() assert(loadScript(protocol.transport))() assert(loadScript(SCRIPT_HOME.."/MSP/common.lua"))() local lastReqTS = 0 local INTERVAL = 50 local MSP_SET_RTC = 246 local reqSent = 0 local function checkTime() if getTime() - lastReqTS > INTERVAL then local now = getDateTime() local year = now.year; values = {} values[1] = bit32.band(year, 0xFF) year = bit32.rshift(year, 8) values[2] = bit32.band(year, 0xFF) values[3] = now.mon values[4] = now.day values[5] = now.hour values[6] = now.min values[7] = now.sec -- send msp message if protocol.mspWrite(MSP_SET_RTC, values) then reqSent = reqSent + 1 end end -- process send queue mspProcessTxQ() end local function run() checkTime() lcd.clear() lcd.drawText(15, 30, "reqSent:", 0) lcd.drawNumber(88, 30, reqSent, 0) return 0 end return { run=run } 
@codecae
Copy link
Member Author

codecae commented Nov 16, 2017

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.

@raphaelcoeffic
Copy link
Member

where? on the BF side?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
3 participants