Firmware for HK 30A UBEC (F-30A) ESC

Blue Robotics Products Speed Controllers (ESCs)
1

Hi,

I cloned the bluerobotics tgy fork and built targetting bs_nfet.hex which I understand to be the correct firmware for the HobbyKing 30A UBEC (F-30A) ESC. However, upon power up, it gives me the 3 note rising tones, but then settles into a single beep every 10-15 seconds regardless what I do. I’m using a servo testor and have tried the calibration routine suggested on the tgy readme.md, but it just sits there a single beeps at me every few seconds with no change.

Thoughts?

Cheers

Mark

2

Mark,

The forward/reverse firmware does not require a calibration. The firmware requires a ‘neutral’ pulse of 1500us before the esc will arm. Once the esc has received a 1500us, it will spin full forward at 1900us and full reverse at 1100us.

3

Thanks for the quick reply. Sorry, I forgot to mention that that’s where I started. I powered up the ESC w/ motor attached w/ the servo tester in the middle. I then played with it slightly below center and over. For context, I have the afro ESCs that I flashed and they work exactly as expected. (However I did flash the afros using the pwm pin instead of my avr pocket programmer) Also, this is the 2nd HK ESC that I’ve tried. Both exhibited the same behavior.

Thanks

4

For further context, the behavior matches the description of f1, f2, f3 (normal boot), and then a single f3 after 8 seconds, and then an f3 every 4 seconds thereafter. For the non-forked simonk firmware, this means invalid pwm signal. However, if I swap in a non-flashed ESC, or a flashed afro, (while changing nothing else) everything works fine.

5

Mark,

I also got bogged down on hacking and flashing uni-directional ESC’s to make them bi-directional.

I have moved to the EMAX BLHeli ESC range. The advantages are;

  • Wide range of ESC's; 6A, 12A, 20A, 25A, 30A, 40A, 50A, 60A, 80A
  • Their EMAX Program card is easy to use and it provides robust and stable programming of 8 parameters, including a bi-directional parameter.
I have found the ESC performance quite satisfactory.
6

Thanks Ed.

Anybody else have any ideas? Folks from BlueRobotics?

 

 

7

Ok, I got the firmware working by changing USE_INT0 to 1, and commented out USE_INT0S in bs_nfet.inc.

If I’m reading the comments in tgy.asm correctly, INT0s appears to be a separate interrupt for the serial protocol that BlueRobotics wrote. Apparently there were glitches due to contention on INT0…

Question: Since I’m not using I2C communications, would this change affect me one way or the other? (my assumption here is that most of this stuff is for blueesc where it gets telemetry via I2C from the esc…please correct me if I’m wrong)

Thanks

8

How should I interpret no replies? (especially from BR) Don’t care? Don’t know? Please leave? Something else? Am I on my own on this one?

Am hoping to get more context from folks at BR who have better insight into the the simonk firmware mods that were done.

9
Don’t care? Don’t know? Please leave?
None of the above, I'm sure. I know Rusty has been traveling and otherwise very busy.

On the subject of you finding the issue in firmware, great job. That is great insight, this should probably be handled with the make target.

I am not positive one way or another if there will be issues with changing USE_INT0 beyond disabling i2c communications. Have you powered the esc and tested it after those changes?

I’m sure Rusty will chime in when he gets the chance.

-Jacob

10

Hi Mark,

Sorry for the lack of reply! My fault. The USE_INT0S flag is actually built into the normal SimonK firmware. That has nothing to do with our modifications. The only files we really touched are the ESC configuration files for the BlueESC and some change in tgy.asm, which are only compiled if you specify the SIMPLE_I2C = 1 in the configuration file. Because of that, you’re basically building a stock version of the tgy firmware that has the MOT_REVERSE flag set to true to allow bidirectional operation.

I would guess that the bs_nfet.inc configuration file was built for a different version of that ESC and they aren’t completely compatible. Could also be a bug.

Our version of tgy is a bit behind the master branch. If you look at that code, it has been updated with this change:

From current tgy master in bs_nfet.inc:


.equ	F_CPU		= 16000000
.equ	USE_INT0	= 1
.equ	USE_I2C		= 0	; We could, but FETs are on the I2C ports
.equ	USE_UART	= 0
.equ	USE_ICP		= 0

I hope this helps! If not, I’d recommend opening an issue on the main tgy repository (GitHub - sim-/tgy: tgy -- Open Source Firmware for ATmega-based Brushless ESCs) and I’m sure Simon will be able to answer this much more thoroughly.

-Rusty