Simple 3D-printed NRF remote - Arduino controlled

Your receiver is either shorting, or not wired up properly all those 0x00’s mean no information is being communicated between the NRF and the Arduino. The NRF could also just be bad.

@monter_man What do you get with debug turned on?

Switched the Tx’s NRF…again. Still will not connect. STATUS = 0xff RX_DR=1 TX_DS=1 MAX_RT=1 RX_P_NO=7 TX_FULL=1 RX_ADDR_P0-1 = 0xffffffff7f 0xffffffffff RX_ADDR_P2-5 = 0x7f 0xff 0x7f 0xff TX_ADDR = 0xffffffff7f RX_PW_P0-6 = 0xff 0x7f 0xff 0x7f 0xff 0x7f EN_AA = 0xff EN_RXADDR = 0x7f RF_CH = 0xff RF_SETUP = 0x7f CONFIG = 0x7f DYNPD/FEATURE = 0x7f 0xff Data Rate = 1MBPS Model = nRF24L01 CRC Length = 16 bits PA Power = PA_MAX 041004b0a: Failed transmission

The Rx is: ⸮⸮<⸮⸮<** Esk8-remote receiver ** Settings loaded Printing receiver details STATUS = 0x00 RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=0 TX_FULL=0 RX_ADDR_P0-1 = 0x0000000000 0x0000000000 RX_ADDR_P2-5 = 0x00 0x00 0x00 0x00 TX_ADDR = 0x0000000000 RX_PW_P0-6 = 0x00 0x00 0x00 0x00 0x00 0x00 EN_AA = 0x00 EN_RXADDR = 0x00 RF_CH = 0x00 RF_SETUP = 0x00 CONFIG = 0x00 DYNPD/FEATURE = 0x00 0x00 Data Rate = 1MBPS Model = nRF24L01 CRC Length = Disabled PA Power = PA_MIN Setup complete - begin listening New package: ‘0-0-0’ Getting VESC data

Getting completely new NRFs tommorow so I’ll try that. Maybe one of the ones I replaced is bad

Can you show us your wiring picture.

sorry I was on vacation.20180807_14542320180806_161733

I did a over 130km across the passes from Chiang Mai to Pai. It tooks 3 charges to complete the route.

10 Likes

Hey everyone, I can’t seem to get telemetry working. How can I match my vesc’s baud rate with my receiver’s? How do I know what my receiver’s baud rate is? I’m using a Focbox with Ackmaniac 3.102 together with an arduino nano (non firefly PCB), dev branch of solidgeek’s code and master branch of rollinggecko’s code.

Probably the packet in Ackmaniac’s is different than the one in the rolling gecko library, you need to compare the bldcmeasure or mc_values struct of booth to see if they are equal

I had this problem with the newer firmwares since Vedder is always adding more things

struct bldcMeasure {
float tempFET;
float tempMotor;
float avgMotorCurrent;
float avgInputCurrent;
float FOCcurrentD;
float FOCcurrentQ;
float dutyCycleNow;
float rpm;
float inpVoltage;
float ampHours;
float ampHoursCharged;
float wattHours;
float wattHoursCharged;
long tachometer;
long tachometerAbs;
mc_fault_code fault_code;
float position;

This structure matches FW from 3.34 to 3.39.

Until now, I always managed to have Rollinggecko’s library working by adding new elements in deserialization. However with FW3.40, by adding 1 byte more (vesc ID) in COMM_GET_VALUES packet, I encounter an issue of packet shorter than expected.

Actually, it seems that now we reach serial buffer limit of Arduino (64 bytes). Packet is : 1 start byte + 1 size type byte + 1 length byte + 59 bytes Payload + 2 CRC bytes + 1 stop byte = 65 bytes… :confounded: The trick to increase buffer size is to modify SERIAL_BUFFER_SIZE in internal file of Arduino core (HardwareSerial.h). Not that hard to do, but it’s not as simple as just adding a library for beginners. :confused:

This is just a clue, I need to test. But that really makes sense.

Hi, thanks for your reply

mc_values struct seems to be the same on ackmaniac’s firmware:

	float v_in;
float temp_mos1;
float temp_mos2;
float temp_mos3;
float temp_mos4;
float temp_mos5;
float temp_mos6;
float temp_pcb;
float current_motor;
float current_in;
float rpm;
float duty_now;
float amp_hours;
float amp_hours_charged;
float watt_hours;
float watt_hours_charged;
int tachometer;
int tachometer_abs;
mc_fault_code fault_code;

I can’t seem to find the bldcMeasure struct within ackmaniac’s firmware. Where is it usually stored? Or is ghe bldcMeasure struct only within the scope of rollinggecko’s library?

Only on the library, you have to see if booth of them match and probably adjust the bit size if I’m not mistaken

I have a library modified by @Pimousse that works on 3.33, if you want I can send for you to try

@neiru37, which FW are you running ? Check my librairies here : https://drive.google.com/open?id=13ZL37tD0YRZzcL2XTEyNG4uAA-xMj4O9

Regarding the buffer size, I’m still struggling to have it working even after had modified the Arduino core :pensive: BTW, I opened an issue on Vedder’s BLDC repo. Will see…

1 Like

Didn’t see your message first, that sucks, I get that new features have to be added, but breaking up a function by upgrading is no good

I’m still on 3.34 by fear of the library stop working again

I confirm that the library (VESC_FW_from_v3.34) is fine up to FW3.39.

Thanks, I will update it

I think the only significant change it the handbrake

Ackmaniac 3.01, rollinggecko master, solidgeek development

Fine as in it works with the firefly firmware?

EDIT: Nvm this is the firefly firmware

Don’t know, I don’t have a Firefly.

I finally got FW3.40 working !!! What a pain in the a** ! I needed to activate compilation output in Preferences then seek for the path of HardwareSerial.h which is actually lost in a hidden folder in the darkness of the Hard drive… :roll_eyes:

Now, buffer size 128 for RX is quite enough for a bunch of FW update I guess :smile: Works with my library VESC_FW_from_v3.40

1 Like

Nice, can you upload it for us mortals? And what I have to change in the arduino ide?

Library is already in my Google drive public (link few post above). Well, nothing to change in Arduino IDE, but in a file in hidden directory, which obviously is different regarding your OS. On my mac : /Users/User/Library/Arduino15/packages/arduino/hardware/avr/1.6.21/cores/Arduino/HardwareSerial.h Open this file and look for SERIAL_RX_BUFFER_SIZE 64. Change 64 by 128. Keep in mind that every Arduino project you will code will have this extended buffer, which also take more memory of course (=less for your code).

1 Like

Thanks a lot

1 Like

is anyone else having issues with the two halves of the cases not meeting exactly on the long edges? I have printed out two of these now in Nylon and the case isn’t an exact fit which is a shame

The original design file has a flaw that causes this. The MicroUSB port doesn’t sit flush in the bottom half for any of my prints. So every remote has a small gap down there

2 Likes

I just downloaded the files from thingiverse, is there a more up to date file?