Fun, Learning, Friendship and Mutual Respect START  HERE


Unregistered
Go Back   HeliFreak > R/C Electronics Support > HobbyWing ESC's


HobbyWing ESC's HobbyWing ESC Support


Like Tree9Likes
Reply
 
LinkBack Thread Tools Display Modes
Old 06-27-2019, 02:12 AM   #1 (permalink)
Registered Users
 

Join Date: Feb 2019
Location: Zurich
Default Hobbywing V3/V4/V5 telemetry to Frsky Smartport with Arduino Pro Mini

Hobbywing V3/V4/V5 telemetry to Frsky Smartport with Arduino Pro Mini

This is a project to send Hobbywing V3/V4/V5 telemetry to Frsky Smartport with an Arduino Pro Mini

Telemetry is read from the telemetry output of the ESC

Alternatively RPM input can be a PWM signal (ESC or phase sensor)

Optionally for HW V5 a PWM signal is generated to feed a FBL system


Basic circuit:




In addition analog sensors can be added to measure voltage, current and temperature



Link to the project on github:

https://github.com/dgatf/esc_smartport


-------------------------

Original post:

https://www.helifreak.com/showthread.php?t=821561

Last edited by DanielGA; 06-27-2019 at 02:38 AM..
DanielGA is offline        Reply With Quote Quick reply to this message
Sponsored Links
Advertisement
 
Old 06-27-2019, 11:36 AM   #2 (permalink)
Registered Users
 

Join Date: Feb 2007
Location: England
Default

Daniel,

I've just got my second heli fully equiped with your solution - in this case it's a Gaui X3L with a R-XSR Rx connected to a 3.3v Arduino running V0.3 and a HW Phase Sensor.

With this set-up my HS matches my Helispeed Tachometer app, and it is much easier to read the HS and voltage with the averaging.

Can I still adjust the averaging?? I find it much easier to read the voltage (2 second averaging from memory) than the HS (0.5 second averaging), so I thought that I might try 1 second averaging for the HS. Personally I don't need it to be as detailed as every 0.5 seconds - every second but with less fluctuation would be preferable for me to read (though possibly not for a Governor).
Mikej is offline        Reply With Quote Quick reply to this message
Old 06-27-2019, 03:57 PM   #3 (permalink)
Registered Users
Thread Starter Thread Starter
 

Join Date: Feb 2019
Location: Zurich
Default

Quote:
Originally Posted by Mikej View Post
Daniel,

I've just got my second heli fully equiped with your solution - in this case it's a Gaui X3L with a R-XSR Rx connected to a 3.3v Arduino running V0.3 and a HW Phase Sensor.

With this set-up my HS matches my Helispeed Tachometer app, and it is much easier to read the HS and voltage with the averaging.

Can I still adjust the averaging?? I find it much easier to read the voltage (2 second averaging from memory) than the HS (0.5 second averaging), so I thought that I might try 1 second averaging for the HS. Personally I don't need it to be as detailed as every 0.5 seconds - every second but with less fluctuation would be preferable for me to read (though possibly not for a Governor).
Yes you can increase the queues sizes

For now averaging and refresh rate are independent

With averaging the limit is the memory usage:

- Each element of the queue is 8B
- Each sensor uses 11B. Assuming 10 sensors (110B)
- Global variables in v0.3 uses 446B
- Reserve 300B for local variables

If using atmega328, remaining ram is 1302B. It should be ok to use up to 162 queue elements in total. If using all sensors, 9, then 18 queue elements per each on average, but you can redistribute them (e.g: rpm 30, volt 10, ntc 5...). Ntc values are very stable, rpms unstable...

If using atmega168 this is reduced to 75 queue elements in total (4 average)

Esc serial is updated every 20ms (packet), but other readings more often (haven't measured) and depends on the board (8mhz or 16mhz)

Refresh rate was intended to substitute averaging and reduce processing time, but it didn't produce good results. Thinking to combine refresh rate and averaging somehow

I recommend to increase averaging and reduce refresh rate until you get a stable and fluent value. I haven't played much with this though

Not yet implemented averaging for governor (I'll define an independent queue for this). It still updates the frequency with instant values

Maybe useful to add averaging and refresh rate to the config script

Last edited by DanielGA; 06-27-2019 at 04:13 PM..
DanielGA is offline        Reply With Quote Quick reply to this message
Old 06-27-2019, 04:43 PM   #4 (permalink)
Registered Users
 

Join Date: Feb 2007
Location: England
Default

Quote:
Originally Posted by DanielGA View Post
Yes you can increase the queues sizes

For now averaging and refresh rate are independent

With averaging the limit is the memory usage:

- Each element of the queue is 8B
- Each sensor uses 11B. Assuming 10 sensors (110B)
- Global variables in v0.3 uses 446B
- Reserve 300B for local variables

If using atmega328, remaining ram is 1302B. It should be ok to use up to 162 queue elements in total. If using all sensors, 9, then 18 queue elements per each on average, but you can redistribute them (e.g: rpm 30, volt 10, ntc 5...). Ntc values are very stable, rpms unstable...

If using atmega168 this is reduced to 75 queue elements in total (4 average)

Esc serial is updated every 20ms (packet), but other readings more often (haven't measured) and depends on the board (8mhz or 16mhz)

Refresh rate was intended to substitute averaging and reduce processing time, but it didn't produce good results. Thinking to combine refresh rate and averaging somehow

I recommend to increase averaging and reduce refresh rate until you get a stable and fluent value. I haven't played much with this though

Not yet implemented averaging for governor (I'll define an independent queue for this). It still updates the frequency with instant values
Crikey - I didn't realise that it was complex

Quote:
Originally Posted by DanielGA View Post
Maybe useful to add averaging and refresh rate to the config script
It would certainly be helpful while tweaking the values to get the best compromise
Mikej is offline        Reply With Quote Quick reply to this message
Old 06-27-2019, 05:22 PM   #5 (permalink)
Registered Users
 
Posts: 13,903
 

Join Date: Dec 2011
Default

How do I enable PWM input for RPM instead of serial. I searched the origin al thread and couldn't find a clear answer (possibly I just missed it) I'd like to test this as the RPM input to eliminate a wonky clone board as a possible cause of the RPM mismatch.
Atomic Skull is offline        Reply With Quote Quick reply to this message
Old 06-27-2019, 11:46 PM   #6 (permalink)
Registered Users
 

Join Date: Feb 2007
Location: England
Default

Quote:
Originally Posted by Atomic Skull View Post
How do I enable PWM input for RPM instead of serial. I searched the origin al thread and couldn't find a clear answer (possibly I just missed it) I'd like to test this as the RPM input to eliminate a wonky clone board as a possible cause of the RPM mismatch.
Use the LUA script, use the scroll button (QX7) to select the top "Protocol" field, then click to select the protocol, then use scroll to change through the protocol options, click select to enable movement to next option, long press "Menu" button to update Arduino
Mikej is offline        Reply With Quote Quick reply to this message
Old 06-29-2019, 04:27 PM   #7 (permalink)
Registered Users
 
Posts: 13,903
 

Join Date: Dec 2011
Default

Quote:
Originally Posted by Mikej View Post
Use the LUA script, use the scroll button (QX7) to select the top "Protocol" field, then click to select the protocol, then use scroll to change through the protocol options, click select to enable movement to next option, long press "Menu" button to update Arduino

I'm using a JR XP9303 with an XJT module.
Atomic Skull is offline        Reply With Quote Quick reply to this message
Old 06-29-2019, 05:23 PM   #8 (permalink)
Registered Users
 

Join Date: Feb 2007
Location: England
Default

Quote:
Originally Posted by Atomic Skull View Post
I'm using a JR XP9303 with an XJT module.
That might make it more tricky

It's really a question for Daniel - but having had a rummage through his code previously "I think" that this might work ...

ESC Protocols are defined in Esc.h

// ESC protocols

#define PROTOCOL_HW_V3 0
#define PROTOCOL_HW_V4 1
#define PROTOCOL_PWM 2


and then the default configuration is defined in esc_smartport.h

// Default config

struct Config {
uint8_t protocol = PROTOCOL_HW_V3;
bool voltage1 = false;
bool voltage2 = false;
bool current = false;
bool ntc1 = false;
bool ntc2 = false;
bool pwmOut = false;

I believe this means that the default config (that can be changed in the LUA) is for HW V3. If you change

uint8_t protocol = PROTOCOL_HW_V3;

to

uint8_t protocol = PROTOCOL_PWM;

I believe that the change should give you PWM as your starting config, you'd obviously have to re-compile, link and download to the arduino

I'm sure that Danial can confirm though ...
Mikej is offline        Reply With Quote Quick reply to this message
Old 06-30-2019, 02:19 PM   #9 (permalink)
Registered Users
Thread Starter Thread Starter
 

Join Date: Feb 2019
Location: Zurich
Default

Sorry but it is not feasible to produce pwm signal from pwm input as they use the same arduino timer (arduino pro mini has only one 16-bit timer). Not feasible to read interrutps and generate pwm output at the same time
DanielGA is offline        Reply With Quote Quick reply to this message
Old 07-10-2019, 04:19 AM   #10 (permalink)
Registered Users
Thread Starter Thread Starter
 

Join Date: Feb 2019
Location: Zurich
Default

Quote:
Originally Posted by Atomic Skull View Post
I'm using a JR XP9303 with an XJT module.
Didn't though on this use case

For this case I've added an option to not use lua script for config (comment #define CONFIG_LUA in esc_smartport.h). This is necessary otherwise whatever is saved on the eeprom will overwrite the defined config in the code

This applies for radios without lua scripts (JR XP9303, Turnigys and/or without opentx firmware)

Then the config can be defined from code in esc_smartport.h inside Struct Config {...}

I've added this case to the Readme on github
DanielGA is offline        Reply With Quote Quick reply to this message
Old 07-10-2019, 04:27 AM   #11 (permalink)
Registered Users
Thread Starter Thread Starter
 

Join Date: Feb 2019
Location: Zurich
Default

Code updates:

v0.2.1 and v0.3:

- Fixed ntc readings bug (was always value 0)
- Fixed bug on PWM IN (in some cases didn't return to 0 rpm)
- Added lua config as an option (#define CONFIG_LUA)

v0.3:

- Added refresh rate and queues to lua script
- Added pwm out (governor) averaging
DanielGA is offline        Reply With Quote Quick reply to this message
Old 07-10-2019, 04:32 AM   #12 (permalink)
Registered Users
Thread Starter Thread Starter
 

Join Date: Feb 2019
Location: Zurich
Default

Quote:
Originally Posted by Mikej View Post

and then the default configuration is defined in esc_smartport.h

// Default config

struct Config {
uint8_t protocol = PROTOCOL_HW_V3;
bool voltage1 = false;
bool voltage2 = false;
bool current = false;
bool ntc1 = false;
bool ntc2 = false;
bool pwmOut = false;

I believe this means that the default config (that can be changed in the LUA) is for HW V3. If you change

uint8_t protocol = PROTOCOL_HW_V3;

to

uint8_t protocol = PROTOCOL_PWM;

That's right. Also comment #define CONFIG_LUA in esc_smartport.h (with latest code) as explained before
DanielGA is offline        Reply With Quote Quick reply to this message
Old 07-10-2019, 12:41 PM   #13 (permalink)
Registered Users
 

Join Date: Feb 2007
Location: England
Default

Daniel, it turns out that my programmer has packed up, so it may be that it was not burning the firmware correctly.

I have ordered another and will report back once it has arrived and I have had a chance to re-flash the firmware...


Daniel,

I'm sorry, but I can't get the latest code working. I have downloaded the new LUA (into the Telemetry folder on the SD card), and downloaded the new firmware onto the Arduino.

The LUA does not communicate with the Arduino (it does not read the config data - protocol field is blank unless I hit reset when I get HW50). Also I do not get any sensors recognised when I do "Discover Sensors" in the telemetry screen.

This is with my previously working config - QX7, Mini Pro 3.3V, HW Phase Sensor - I literally downloaded the new firmware onto the board that I have been using for the past couple of weeks with the previous software, but now it doesn't work. I've tried with another board (that worked with the old firmware) without success.

Edit:
I have just reloaded the V0.3 from 25th June (LUA and Arduino firmware) and it immediately works again.

Last edited by Mikej; 07-11-2019 at 08:46 AM..
Mikej is offline        Reply With Quote Quick reply to this message
Old 07-10-2019, 08:34 PM   #14 (permalink)
Registered Users
 
Posts: 13,903
 

Join Date: Dec 2011
Default

Quote:
Originally Posted by DanielGA View Post
Code updates:

v0.2.1 and v0.3:

- Fixed ntc readings bug (was always value 0)
- Fixed bug on PWM IN (in some cases didn't return to 0 rpm)
- Added lua config as an option (#define CONFIG_LUA)

v0.3:

- Added refresh rate and queues to lua script
- Added pwm out (governor) averaging

Any fix yet for the RPM difference between telemetry and actual RPM?
Atomic Skull is offline        Reply With Quote Quick reply to this message
Old 07-11-2019, 06:25 PM   #15 (permalink)
Registered Users
 
Posts: 13,903
 

Join Date: Dec 2011
Default

Experimented a bit today. This is pole pairs?
Quote:
uint8_t queuePwm = 5;
Averaging is enabled by increasing the value?
Quote:
float pwmAvg = 0;
What do these values actually mean in regards to time? increasing it to 20 didn't seem to have any noticeable effect on the PWM signal stability. Or am I doing it wrong? I think I'd be ok doing a test hover even with the RPM inaccuracy just to see how an FBL governor works with the PWM output from the arduino. The RPM would be a little off but it should still work.
Atomic Skull is offline        Reply With Quote Quick reply to this message
Old 07-12-2019, 12:33 AM   #16 (permalink)
Registered Users
Thread Starter Thread Starter
 

Join Date: Feb 2019
Location: Zurich
Default

Quote:
Originally Posted by Mikej View Post
Daniel, it turns out that my programmer has packed up, so it may be that it was not burning the firmware correctly.

I have ordered another and will report back once it has arrived and I have had a chance to re-flash the firmware...


Daniel,

I'm sorry, but I can't get the latest code working. I have downloaded the new LUA (into the Telemetry folder on the SD card), and downloaded the new firmware onto the Arduino.

The LUA does not communicate with the Arduino (it does not read the config data - protocol field is blank unless I hit reset when I get HW50). Also I do not get any sensors recognised when I do "Discover Sensors" in the telemetry screen.

This is with my previously working config - QX7, Mini Pro 3.3V, HW Phase Sensor - I literally downloaded the new firmware onto the board that I have been using for the past couple of weeks with the previous software, but now it doesn't work. I've tried with another board (that worked with the old firmware) without success.

Edit:
I have just reloaded the V0.3 from 25th June (LUA and Arduino firmware) and it immediately works again.

The main issue is that the first time the queue size is read the value is 255 (0xFF) as previously unused bytes from the eeprom are filled with 0xFF. This queue sizes causes ram overflow, then the arduino gets halted. I'm limiting the queue size to avoid this

Other issues are:

Sending telemetry packets needs to be stopped when talking to lua or there are chances of missing a config packet. Before it was 1 packet for config and worked ok, but now there are 2 packets and sometimes 1 is lost. For this I'm implementing a maintenance mode, which is also used in other frsky sensors

There seems to be a bug in lua opentx which causes the higest byte of the packets unusable. I'll divide the config in 3 packets, rather than 2

Fixing those issues. I'll update the code soon

Last edited by DanielGA; 07-12-2019 at 06:58 AM..
DanielGA is offline        Reply With Quote Quick reply to this message
Old 07-12-2019, 03:48 AM   #17 (permalink)
Registered Users
Thread Starter Thread Starter
 

Join Date: Feb 2019
Location: Zurich
Default

Quote:
Originally Posted by DanielGA View Post
The main issue is that the first time the queue size is read the value is 255 (0xFF) as previously unused bytes from the eeprom are filled with 0xFF. This queue sizes causes ram overflow, then the arduino gets halted. I'm limiting the queue size to avoid this

Other issues are:

Sending telemetry packets needs to be stopped when talking to lua or there are chances of missing a config packet. Before it was 1 packet for config and worked ok, but now there are 2 packets and sometimes 1 is lost. For this I'm implementing a maintenance mode, which is also used in other frsky sensors

There seems to be a bug in lua opentx which causes the 4th byte of the packets unusable. I'll divide the config in 3 packets, rather than 2

Fixing those issues. I'll update the code soon

All issues fixed. Code updated on github

Also fixed a bug in pwm out (governor) queue
DanielGA is offline        Reply With Quote Quick reply to this message
Old 07-12-2019, 03:56 AM   #18 (permalink)
Registered Users
Thread Starter Thread Starter
 

Join Date: Feb 2019
Location: Zurich
Default

Quote:
Originally Posted by Atomic Skull View Post
Experimented a bit today. This is pole pairs? Averaging is enabled by increasing the value? What do these values actually mean in regards to time? increasing it to 20 didn't seem to have any noticeable effect on the PWM signal stability. Or am I doing it wrong? I think I'd be ok doing a test hover even with the RPM inaccuracy just to see how an FBL governor works with the PWM output from the arduino. The RPM would be a little off but it should still work.
config.queuePwm is the number of averaging elements. This is what you need to adjust. Pole pairs are only defined in the radio. All rpm in the code are electric rpm: electric rpm = rpm * pair of poles. I've tested and governor averaging is ok now. Download the latest code as there was a bug related to this queue

telemetry.pwmAvg is the actual averaged value of the pwm out signal. Don't modify it. You can use it for debugging

All config is defined in:

Code:
struct Config {
  uint8_t protocol = PROTOCOL_HW_V3;
  bool voltage1 = false;
  bool voltage2 = false;
  bool current = false;
  bool ntc1 = false;
  bool ntc2 = false;
  bool pwmOut = false;
  uint8_t refreshRpm = 2;
  uint8_t refreshVolt = 10;
  uint8_t refreshCurr = 10;
  uint8_t refreshTemp = 10;
  //max queue size 16
  uint8_t queueRpm = 5;
  uint8_t queueVolt = 5;
  uint8_t queueCurr = 5;
  uint8_t queueTemp = 5;
  uint8_t queuePwm = 5;
};
Don't modify any value in struct Telemetry as those are the actual values of the sensors. You can use them for debugging

Remember to comment #define CONFIG_LUA if not using lua script

Last edited by DanielGA; 07-12-2019 at 06:27 AM..
DanielGA is offline        Reply With Quote Quick reply to this message
Old 07-12-2019, 07:31 AM   #19 (permalink)
Registered Users
 

Join Date: Feb 2007
Location: England
Default

Daniel,

My new programmer arrived - still no success I'm afraid - this is what I get if I run with debug on

DEBUG
V0.3.0
Read config
Protocol: 0
Voltage1: 0
Voltage2: 0
Current: 0
NTC1: 0
NTC2: 0
Pwm out: 0
Refresh RPM: 255
Refresh Volt: 255
Refresh Curr: 255
Refresh Temp: 255
Queue RPM: 5
Queue Volt: 5
Queue Curr: 5
Queue Temp: 5
Queue PWM: 5

Basically I still can't communicate between the LUA and the Arduino and the Arduino doesn't appear to try to output (no led activity)
Mikej is offline        Reply With Quote Quick reply to this message
Old 07-12-2019, 08:18 AM   #20 (permalink)
Registered Users
Thread Starter Thread Starter
 

Join Date: Feb 2019
Location: Zurich
Default

Quote:
Originally Posted by Mikej View Post
Daniel,

My new programmer arrived - still no success I'm afraid - this is what I get if I run with debug on

DEBUG
V0.3.0
Read config
Protocol: 0
Voltage1: 0
Voltage2: 0
Current: 0
NTC1: 0
NTC2: 0
Pwm out: 0
Refresh RPM: 255
Refresh Volt: 255
Refresh Curr: 255
Refresh Temp: 255
Queue RPM: 5
Queue Volt: 5
Queue Curr: 5
Queue Temp: 5
Queue PWM: 5

Basically I still can't communicate between the LUA and the Arduino and the Arduino doesn't appear to try to output (no led activity)
Didn't realized that refresh rates also needs to be limited first time are read from eeprom (255 value is 25.5s refresh rate). This could produce some issues

Try with the updated code. I haven't updated the lua script now, but this morning I did. Copy to sd card if you haven't done since yesterday

Last edited by DanielGA; 07-12-2019 at 08:31 AM..
DanielGA is offline        Reply With Quote Quick reply to this message
Reply




Quick Reply
Message:
Options

Register Now

In order to be able to post messages on the HeliFreak forums, you must first register.
Please enter your desired user name, your REAL and WORKING email address and other required details in the form below.
User Name:
Password
Please enter a password for your user account. Note that passwords are case-sensitive.
Password:
Confirm Password:
Email Address
Please enter a valid email address for yourself. Use a real email address or you will not be granted access to the site. Thank you.
Email Address:
Location
Where do you live? ie: Country, State, City or General Geographic Location please.
Name and Lastname
Enter name and last name here. (This information is not shown to the general public. Optional)
Helicopter #1
Enter Helicopter #1 type and equipment.
Helicopter #2
Enter Helicopter #2 type and equipment.
Helicopter #3
Enter Helicopter #3 type and equipment.
Helicopter #4
Enter Helicopter #4 type and equipment.

Log-in


Thread Tools
Display Modes

Posting Rules
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On




Copyright © Website Acquisitions Inc. All rights reserved.
vBulletin Security provided by vBSecurity v2.2.2 (Pro) - vBulletin Mods & Addons Copyright © 2021 DragonByte Technologies Ltd.

SEO by vBSEO 3.6.1