Originally Posted by RedSky

Hi Steve, In spite of earlier casting doubt on the new FW with the MT4008 motors I've done a day of bench testing and I'm now satisfied that the motors run reliably with the new FW flashed F30As. Even with furious working of the servo tester the motors never missed a beat.

Attached is part of my test results - as you can see my new Graupner 14x8 E-Props are spectacularly better than the Chinese 13x6.5 and 14x4.7 CF props I've been using but the cheap RC Timer 3536/11 with the also cheap Gemfan 11x4.7 didn't do too badly at all. The throttling response of the flashed F30A and the RCTigermotor T40-A seem similar but the maximum power with the F-30As is well down on that available with the T40A.

I don't have an oscilloscope but I now feel comfortable that the latest SK firmware runs the MT4008/12 reliably.

Hello! Good to hear that the MT4008/12 seems to be fine.

Other than some differences from the timing advance, almost any ESC at full throttle should be drawing about the same power and resulting in about the same RPM. The 40A ESC will likely have FET drivers and be a bit more efficient, but at full throttle this goes out the window because there are no more PWM losses. Is that a Hobbywing program style T40A? (Eg: Does it sound like a Plush?)

The closest I have to to that is a SiLabs-based T-Motor Advance-18A with the Hobbywing program, and the RPM is almost identical on an MT-3506 with that at full throttle compared to it swapped out with a flashed F-30A. I suspect either that or the calibration points are different or the voltage is lower when you did the F-30A tests.

Originally Posted by LittleMo

avrdude: verification error, first mismatch at byte 0x0840

It appears the bootloader is not erasing (setting to 0xFF) the empty space as the pages are flashed, therefore leaving data from the old firmware in some circumstances like this where the new firmware is smaller than the old. Verify then fails because it expects 0xFF in the empty space.

Normally this is not an issue because of chip erase but with the bootloader we need something else. Does the Arduino bootloader automatically erase these gaps between data?

I think the WinAVR srec tool "srec_cat" can fix the hex file by filling the gaps with 0xFF.

Hi, LittleMo! I forgot to ask you about this before. Did the srec_cat fix it?

The pages are erased before flashing over them, but one thing I am not doing is pading the temporary page buffer to the page size. Based on the examples and docs it didn't seem like this was needed, but maybe it is. If padding it in the .hex file fixes it, I'm surprised there are not more problems reported. Let me know, I will do some more digging.

2x more ESC's successfully flashed and tested:
- i posted Mystery Cloud 50A photo earlier:

flashed with rb50a.hex (with SLOW_THROTTLE, BRAKE) - works OK. Looks the same as RedBrick 50A.
- Himodel 70A ESC: http://www.himodel.com/electric/HiMo...X-70A-BEC.html - it's the same as RedBrick 200A, just much cheaper. Used birdie70a.hex (again with SLOW_THROTTLE, BRAKE) - works OK, but didn't tested with more than 40A (no spare motor that could take such current). Only problem - MLF package, not so easy to solder pins...

Originally Posted by simonk

Hi, LittleMo! I forgot to ask you about this before. Did the srec_cat fix it?

The pages are erased before flashing over them, but one thing I am not doing is pading the temporary page buffer to the page size. Based on the examples and docs it didn't seem like this was needed, but maybe it is. If padding it in the .hex file fixes it, I'm surprised there are not more problems reported. Let me know, I will do some more digging.

"avrdude: verification error, first mismatch at byte 0x0840"

Yeah, i've same error if i flash via usb the wii-esc firmware (without verification error) and then the SimonK, all using the wii-esc flash tool.
But esc apparently it works properly.

Marco

Originally Posted by simonk

Hi, LittleMo! I forgot to ask you about this before. Did the srec_cat fix it?

The pages are erased before flashing over them, but one thing I am not doing is pading the temporary page buffer to the page size. Based on the examples and docs it didn't seem like this was needed, but maybe it is. If padding it in the .hex file fixes it, I'm surprised there are not more problems reported. Let me know, I will do some more digging.

And I forgot to report back.

No, srec_cat does not fix it because apparently avrdude automatically skips the 0xFF bytes as an optimization. Or at least that's what it looks like. When writing with avrdude I can see it still skipping over the empty pages despite having filled them in with 0xFF in the hex file. In any case the verify fails in exactly the same place.

I also forgot to mention that I looked at the Arduino bootloader and it does appear to pad the pages with 0xFF as part of writing them out. Apparently there is some sort of "page erase" command too.

New release of ArduinoUSBLinker v0.8.

Changed some things to make it more compatible with smaller devices (eg. ATmega168 devices). Lower RAM usage, slower default baud rate of 19200 except in MultiWii where it now defaults to whatever baud rate MultiWii is using. I recommend increasing the baud rate to 115200 or 57600 for best performance if your device supports it.

Serial port rate can now be changed on the fly (not for MultiWii).

Added the ability to store the pin, bit rate, and baud rate settings in EEPROM (not for MultiWii).

https://github.com/c---/ArduinoUSBLinker

1. I flashed some RCTImer 10A ESCs with the recommend TGY firmware. They seem to be loosing synch and drop a motor while in operation...which leads to unceremonious drops to the ground. Here's the kicker though. They only seem to be doing this on my Tricopters (tried in two different frames with different brand motors). The same ESCs and firmware in my Hex have no issues and have never dropped a motor in flight. So...is there a different, recommended firmware for these ESCs or, for some reason, is control of a tricopter harder on the ESCs than a quad or higher, thus things loose synch?

2. I have so of the HK Multistar ESCs (10A, 15A, 20A). How do I know which firmware I should try on these? The 'list' only shows the 30A with the KDA (I think) firmware. Is it a guess on which firmware to use or is there a method of which to select?

Thanks in advance for inputs...

Originally Posted by simonk

Hello! Good to hear that the MT4008/12 seems to be fine.

Other than some differences from the timing advance, almost any ESC at full throttle should be drawing about the same power and resulting in about the same RPM. The 40A ESC will likely have FET drivers and be a bit more efficient, but at full throttle this goes out the window because there are no more PWM losses. Is that a Hobbywing program style T40A? (Eg: Does it sound like a Plush?)

The closest I have to to that is a SiLabs-based T-Motor Advance-18A with the Hobbywing program, and the RPM is almost identical on an MT-3506 with that at full throttle compared to it swapped out with a flashed F-30A. I suspect either that or the calibration points are different or the voltage is lower when you did the F-30A tests.

The Tigermotor T40A is a Silabs based device. It has 2 big caps on the input side and I'm afraid that's about where my technical knowledge ends!

I did control the voltage as well as I could (and redid the test after as I was surprised at the thrust difference) - I used a single Hyperion 4S 3300 at storage level (60% on my Cellpro charger) which is about 15.25V. Both ESCs were calibrated using the sameDX8 but it might be worth doing again. The Tigermotor T40A is claimed to have very low resistance - could that be accounting for the difference?

Subsequently I've done some more tests on the RC Timer 3536 with different props and got some very encouraging results with the Gemfan 13x4 wood prop. Next I'll be trying out my iBM 2814Q motors - those or the RC Timers will go in my 2900g quad. The 7kg Octo will be getting the MT4008s.

Originally Posted by ABLomas

2x more ESC's successfully flashed and tested:
- i posted Mystery Cloud 50A photo earlier:
- Himodel 70A ESC:

Hello! Thanks! Added to the spreadsheet.

I think the HiModel GX series, the HK-SS, and the Red Brick and Birdie ESCs probably are all made at the same factory. The 50A, 70A, 200A, etc. models are usually _not_ consistent, though. You may find if you order one the next month it will be a different pin arrangement.

Originally Posted by LittleMo

apparently avrdude automatically skips the 0xFF bytes as an optimization. Or at least that's what it looks like. When writing with avrdude I can see it still skipping over the empty pages despite having filled them in with 0xFF in the hex file. In any case the verify fails in exactly the same place.

I also forgot to mention that I looked at the Arduino bootloader and it does appear to pad the pages with 0xFF as part of writing them out. Apparently there is some sort of "page erase" command too.

Can you send me or point me to the .hex which is failing? I've tried to construct one that fails, but it is not. I did switch to avrdude from svn a while ago, though, because there seemed to be a bug in writing the EEPROM that seem to be fixed. I believe it was mixing up words and bytes when sending the EEPROM address, so it would only work if the stream starts at 0.

Originally Posted by Vantasstic

1. I flashed some RCTImer 10A ESCs with the recommend TGY firmware. They seem to be loosing synch and drop a motor while in operation...which leads to unceremonious drops to the ground.

RCTimer 10A ESCs seem to have an electrical problem that can cause the MCU to reset under high current. This is probably what is happening instead of a timing loss, unless you hear the sound of it trying to drive the motor still. Does it happen when you make an abrupt move?

Originally Posted by Vantasstic

2. I have so of the HK Multistar ESCs (10A, 15A, 20A). How do I know which firmware I should try on these? The 'list' only shows the 30A with the KDA (I think) firmware. Is it a guess on which firmware to use or is there a method of which to select?

I only got the 30A, but I think they are all kda.hex. You can try and see how it goes. If it works, let me know. I will add to the spreadsheet.

Originally Posted by simonk

Can you send me or point me to the .hex which is failing? I've tried to construct one that fails, but it is not. I did switch to avrdude from svn a while ago, though, because there seemed to be a bug in writing the EEPROM that seem to be fixed. I believe it was mixing up words and bytes when sending the EEPROM address, so it would only work if the stream starts at 0.

I just tried the avrdude from SVN and that appears to fix the problem.

I was using avrdude version 5.11.1 which does not work if you want to try to recreate the issue. My ESC had the 2012-09-30 bs_nfet and I was flashing the latest bs_nfet from git which is a smaller .hex file.

I have a feeling it might be worth it to work around the problem if possible because who knows when all the tools will upgrade avrdude.

For Simon?

manu

Esc - motor - prop compability
http://www.rcgroups.com/forums/showp...&postcount=236

Originally Posted by simonk

RCTimer 10A ESCs seem to have an electrical problem that can cause the MCU to reset under high current. This is probably what is happening instead of a timing loss, unless you hear the sound of it trying to drive the motor still. Does it happen when you make an abrupt move?

Thanks for the reply. No, I'll complete loose a motor (no noise, no trying to turn, just stops). I've had it happening in just a hover at low power, smooth forward flight, and a couple of times in power climbs. I've actually lost a motor (usually different motors) in low power situations. Now the exact same ESCs and motors on my little hex and Mutliwii controller have NEVER dropped a motor. It's almost like more/quicker adjustments are required for a tricopter (which is where I'm having my problems) than other frame types. I'm thinking of putting four RCT 10A on my F330 quad to see if they do the same thing there or will operate normally, just like they do on the hex. I've had this problem on two different small tricopter (8" arms) with different controllers and different motors and always loosing a motor in flight.

I only got the 30A, but I think they are all kda.hex. You can try and see how it goes. If it works, let me know. I will add to the spreadsheet.

Great, thank you. I had some Multistar 10A on my little Tricopter, but it would end up with wobbles that I couldn't tune out with the PIDs. I can try flashing them with the KDA file (have to solder on the programmer leads though...no pads. First I think I'll try my flashed Dynam 12A on the mini-tri and the RCTimer 10A on my mini quad for a little troubleshooting.

Hallo Simon,
you can also Adding following ESC´s to your spreadsheet:

Aeolian Evolution 60A (its the same like the Plush 60A) and
Turnigy Plush 60A Esc.

I flashed both with the tp_nfet.hex file. and the are all running very fine.

Does anyone have schematics for the F-30A or F-20A ESCs? They don't use the standard mosfet drivers.

Originally Posted by LittleMo

I just tried the avrdude from SVN and that appears to fix the problem.

I was using avrdude version 5.11.1 which does not work if you want to try to recreate the issue. My ESC had the 2012-09-30 bs_nfet and I was flashing the latest bs_nfet from git which is a smaller .hex file.

I have a feeling it might be worth it to work around the problem if possible because who knows when all the tools will upgrade avrdude.

Ok, I see it with git HEAD bs_nfet.hex and avrdude 5.11.1 as well:

avrdude.stock: verification error, first mismatch at byte 0x0840
0xff != 0x95

It actually seems to be writing the same thing, just verifying incorrectly. The bug seems to be in the optimization for jumping over holes. Flashing unfinished pages is fine, and flashing a small single-part .hex is fine, but when flashing a .hex file with holes or pages with just 0xff, it complains about the parts in the middle that it never flashed containing non-0xff data. This didn't show up before because the main code segment hasn't shrunk since the boot-loader addition until now.

The problem is that the writing part still optimizes all-0xff pages away (the same as the address not being specified), but the verification still forgets about it (even with -D(on't erase)), so I don't see a way of working around avrdude's bug unless I make the boot loader try to tidy up after the end of the main segment before avrdude can read it back. It works if we pad it with nops (0x00) instead...or I guess I could just only release new versions when there are enough new features to make it bigger.

Originally Posted by Razor_Racer

Does anyone have schematics for the F-30A or F-20A ESCs? They don't use the standard mosfet drivers.

It's the "Mystery-nFET" schematic.