Certified FOCBOX Suppliers | Focbox Unity 4 Day Sale

Simple 3D-printed NRF remote - Arduino controlled

electronics
remote
3d

#1472

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?


#1473

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


#1474

Can you show us your wiring picture.

sorry I was on vacation.

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


#1475

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.


#1476

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;

#1477

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.


#1478

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?


#1479

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


#1480

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


Vesc 4.12 and arduino uart
#1481

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


#1482

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


#1483

Thanks, I will update it

I think the only significant change it the handbrake


#1484

Ackmaniac 3.01, rollinggecko master, solidgeek development

Fine as in it works with the firefly firmware?

EDIT: Nvm this is the firefly firmware


#1485

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


#1486

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


#1487

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


#1488

Thanks a lot


#1489

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


#1490

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


#1491

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