nrf24_multipro
nrf24_multipro copied to clipboard
eachaine h8 mini (blue board)
Hi,
is seems that h8 mini (blue board) has changed the protocol. Is there any way to check it?
Alex
Where did you read that ? All the blue boards I've seen are using the same protocol than the green ones.
just an assuption by failing to connect =) that is why i'm looking for a way to check it.
Have you checked your module with another machine ?
no, i have no other copters to check. so yes the problem might be in my build
Yes, triple check your wiring, make sure you give only 3.3 Vcc to the nrf24l01, and depending of the transmitter you're using you probably have to adapt the level of the PPM output to 0-3.3V.
i'm overrided protocol selection to bind to copter regardless the ppm values. is there a way to check arduino-nrf24 connection?
yes, check if NRF24L01_Reset() returns 1.
TY, i will check it in few days and will let you know.
hi again, NRF24L01_Reset() returns zero. im using arduino uno to debug and printing to port monitor
ok i found the issue! THank you kindly!
Cool, can you explain the issue you had ?
connection order( but now i can see an other issue - on low throlette the motors spinnig with interrupts
also on hight trollette, can this be a connection interrupt or something?
Check your antenna, also, if you're using a nrf24l01 module with PA+LNA the 3.3V output of your Uno might not be able to provide enough current. In this case you can try a lower RF output power.
no im powering nrf24l01 with separated 3.3v bec. i checked the operating voltage -3.29 so shoud be fine. also found some trolette action when the thorelette at minimum, if you need i can make a video to show.
Maybe the problem is your PPM output then, have you checked its voltage (with a scope, this can't be done with a simple multimeter ...) Which transmitter are you using ?
i dont have a scope to check it, the only way on my mind to debug it is to print throlette values to the port monitor of arduino IDE.
Yes you can try that, but try to display the value only once per second for example (in update_ppm()), because I think using the UART too much will mess with PPM interrupt.
can you please advice how to do that? im not that good with time delayed tasks. also what is a good place in code to set prints?
put that at the end of update_ppm:
static uint32_t next=0; if(millis() > next) { next = millis()+1000; println(ppm[THROTTLE]); }
yes the numbers are not stable:
1252 1186 1414 1199 1415 1187 1414 1414 1011 1000 1413 1000 1414 1414 1414
Which transmitter are you using ? You need to adapt the level of the PPM output (in hardware).
AT9
Do you have a n-mosfet handy ?
yes STN4NF20L, it is supplyed with 3.3 BEC througth the 10k resistors on vcc and ppm
Here's a schematics, it should work with virtually any small power n-channel mosfet, such as the ones used to drive the motors in small toy quads. http://i.imgur.com/Km99vxX.png
If you do not have a n-mosfet you can try to make a voltage divider with 2 resistors, but I can't recommend a ratio for the 2 resistor as I've no idea of the voltage of your PPM output. The n-mosfet solution is more universal.
the 4NF20L should be fine, its Gate threshold voltage is low enough.
also the ppm signal is stable as i checked it with simulator flights
On some transmitters, the PPM output is open drain, in this case, try to add a 10K resistor between PPM output (PPM_IN in the schematics) and +3.3V to pull it up.
i added 10K resistor to pull up, if i use your print it looks fine but if i print more often sometimes i can see that:
1373 1000 1000 1000 1373 1373 1373 1373 1365 1365 1365 1374 1374 1374 1374 1374