Crazyflie 2.0 with GPS

[arnaud]

I'm having trouble flashing my nRF51 change to turn on N_IO_1. In my VM Eclipse environment I modified the Makefile setting to S110 ?=0 and BLE ?=0. Then in Make Target I did a “clean”, “all(no BLE)” and “flash”. I held the CF2 power button on for 3 seconds waiting for M2 to flash before doing “the “flash”. The error I see is “open failed - in procedure transport and procedure init” What am I doing wrong? I'm trying to do the flash using radio. Do I need to use a cable? I tried a cable and it didn't work.

The V_BCKP pin on the M8 gps needs to be 3.0V and draws 100 uA so N_IO_1 should be sufficient. What is the voltage on this pin? If higher than 3.6V, I'll try a resistor voltage divider network to bring its voltage down a little lower.

You should build only with BLE=0, do not touch S110. S110 is required by the bootloader and erasing the chip requires a JTAG cable.

The NRF51 is powered with 3.0V so ther should not be any problem with the voltage. We have actually been experimenting with holding v_bkp with a GPIO and it worked.

As for the client they are similar on Windows and Linux. I am still working on making the communication more reliable. The Crazyflie 2.0 seems to drop uplink packet which should not be possible. I have seen that disabling bluetooth helps a little bit though.

Using the bootloader in cfcient I was able to load the stm32 and nRF51 bin files. However, when I tried including the nRF51 bin file generated using VM Eclipse all(no ble) build ,it failed with M2 led staying solid and unresponsive to the power on/off switch.

This is normal if you disabled S110. Disabling S110 links the program for the begining of the flash instead of after the S110 stack (the memory architecture is there https://github.com/bitcraze/crazyflie2- ... chitecture). If you do not have a JTAG cable you cannot (easily) remove the S110 stack so compiling with only BLE=0 and keeping the default S110=1 will solve this problem.

[jackemoore]

Hi
Thanks for your reply. Okay, I enabled N_IO1 and see 3V on the deck (expansion board) port. My implementation in nRF51 must be incomplete because the 3V goes away when the CF2 is switched off. My code changes include adding “nrf_gpio_cfg_output(N_IO1_PIN);” & “nrf_gpio_pin_set(N_IO1_PIN);” within pm.c, and adding “#define N_IO1_PIN 11” & changing from “#define WKUP_PIN 11” to “#define WKUP_PIN 12” in pinout.h. The deck port N_IO1 is tied to nRF51 pin 17 (P0.11) and WKUP is tied to nRF51 pin 18 (P0.12).

I tried putting the pm.c changes one trial at a time in functions pmInit, pmDummy, pmNrfPower, pmPowerSystem, and pmRunSystem and couldn't get the 3V to stay on after switch off. Sorry, still need your help again.

When comparing the counts of lost & delayed packets between nRF51 build crf2_nrf_1.1.bin (46,072 bytes) and VM Eclipse preinstalled crazyflie2-nrf-firmware using all(no BLE) build crf2_nrf.bin (25,316 bytes), in my observations the later has far more occurrences.

[tobias]

I tried putting the pm.c changes one trial at a time in functions pmInit, pmDummy, pmNrfPower, pmPowerSystem, and pmRunSystem and couldn't get the 3V to stay on after switch off. Sorry, still need your help again.

Ahh, something I foreseen. When nRF51 is set in OFF mode the GPIO will not work. I think the GPS backup consumes so little a pull-up will be sufficient? The pull-up will stay even in off mode.

[jackemoore]

Hi,
Using your suggestion N_IO1 pin maintains a positive voltage (at no load 3.567V when cf2 is switched off and 2.989V when switched on). Haven't tried it yet, but 100uA draw at 3V from V_BCKP might be feasible and requires testing (applying a 33k ohm load brought the pin voltage down to 2.1V).

Regarding the nRF51 pin assignments the cf2 schematic documentation needs to be corrected.

Just an observation, after incorporating the nRF51 VM Eclipse all(no BLE) build into the cf2 and sending almanacs, I observed 40 lost packets and 13 delayed packets. I'm wondering if the delayed packets (> 4 seconds) are somehow correlated with follow-on requests to transfer packets to the cf2. Also, I observed one instance where the same delayed packet appeared twice one following the other. I've not seen this extreme nor the case of a duplicate delayed packets any time before when using the crf2_nrf_1.1.bin.

[tobias]

Using your suggestion N_IO1 pin maintains a positive voltage (at no load 3.567V when cf2 is switched off and 2.989V when switched on). Haven't tried it yet, but 100uA draw at 3V from V_BCKP might be feasible and requires testing (applying a 33k ohm load brought the pin voltage down to 2.1V).

The ~3.5V is because of not loading the regulator enough (CF2 around 10uA in when switched off). As soon as you connect it to the GPS backup I expect it to go to ~3.0V

Thanks for noticing. The schematics needs even more renaming compared to the deck port pinout diagram.

Arnaud knows more about the data transferring and will have a look at it. Do you happen do have your code available so we might be able to reproduce?

[jackemoore]

Hi,
I must have misunderstood when you suggested a pullup. Correct me if I'm wrong, but I assume GPIO output (3V) is turned off when the nRF51 is in sleep mode. GPIO input does remains on, for example monitoring when the button/switch is pushed and makes contact with signal ground. With GPIO input you can set the pin high or low, but since it's an input a load on the pin to ground would move it towards the off state. My previous comment regarding N_IO1 voltage with a 33k ohms load is based on the pin setup for GPIO input with pullup and this would only supply 64 uA at 2.1V. Hence I assume more investigation is needed or possibly tying WKUP and N_IO1 together if such a thing is ok. If your suggesting instead a hardware change to get the 3V, it looks a little difficult to perform this. VCOM would be ideal, but it's switched off before going to the deck port.

I've made my code available at https://github.com/jackemoore/cf2-stm-gps-2-ebx-io.git branch gpstab-ebx-io for the firmware and at https://github.com/jackemoore/cfclient-gps-2-ebx-io.git branch gpstab-almanactab for cfclient. Some summary comments on what I've done are in README.txt located in both directories. Not sure you would want to go to the trouble of trying to duplicate what I'm seeing regarding packet errors, but that's your decision to make.