8bit vs 32bit Alexmos

[Silverburn]

I'm in the market for a decent Nex5-level gimbal, as an upgrade from my crappy RCtimer ASP, which I have never been able to get to run correctly/smoothly, even on Alexmos 2.4. It either buzzes, or vibrates, and the happy window inbetween is almost non-existent.

So I'm toying with one of these:
http://quadframe.com/collections/frontpage/products/medium-size-bldc-gimbal-v2

However, I also see that there are 32bit boards for Alexmos coming out...Is there a benefit to this, or will my old 8bit continue to work ok? I won't be using the 3rd axis. What does 32bit offer over the 8bit?

http://www.rcshutter.com/index.php?route=product/product&product_id=99

 

[SMP]

For Nex5 and lower weight cameras - suggest you stay with the 8bit as the 32 bit has a much narrower tuning range. For larger cams, DSLRs and handheld rigs the 32 bit offers additional processing power and double IMU options. Its also very expensive and still in development. Preordered the 32bit v 4.0 - waited months, got it and three weeks later price went to 300 and a version 4.5 board... grr.

 

[gtranquilla]

I have it now and am not aware of a narrower tuning range. Can you clarify? The 2nd IMU to be mounted to the frame or below the Yaw motor is supposed to significantly improve performance.

For Nex5 and lower weight cameras - suggest you stay with the 8bit as the 32 bit has a much narrower tuning range. For larger cams, DSLRs and handheld rigs the 32 bit offers additional processing power and double IMU options. Its also very expensive and still in development. Preordered the 32bit v 4.0 - waited months, got it and three weeks later price went to 300 and a version 4.5 board... grr.

 

[tombrown1]

I've noticed zero performance improvement with my 32. Very disappointed and actively looking for something that can give a reasonable horizon for reasonable money.

 

[gtranquilla]

So is the 2nd IMU mounted above or below the Yaw motor? And is the software configured to allow the BGC to see the FC pitch and yaw outputs? Both are supposed to help with BGC precision etc. What is your camera and what BGC motors are you using?

I've noticed zero performance improvement with my 32. Very disappointed and actively looking for something that can give a reasonable horizon for reasonable money.

 

[tombrown1]

So is the 2nd IMU mounted above or below the Yaw motor? And is the software configured to allow the BGC to see the FC pitch and yaw outputs? Both are supposed to help with BGC precision etc. What is your camera and what BGC motors are you using?

Below yaw. I messaged my supplier who said that using fc inputs wouldn't offer any additional benefits over 2 imus.
Using a gh3 with 5206 motors. Stability is fine - horizon still wanders from time to time. I've done advanced calib on both imus and tried just about every gyro trust setting. Still wanders like 8 bit on 1 imu.

 

[gtranquilla]

Yes the horizon will wander from time to time as per the conditions as stated in GUI version 2.41 documentation. I believe this is a laws-of-physics boundary limitation because the IMUs do not contain magnetometer(s) as does the MR FCs for more precise horizon detection. But with the Basecam 32 bit BGC s.bus connectivity to the FCs now available it would appear that in due course, with some additional firmware development, there might be a solution for that issue.
However s.bus mapping can vary such that the FC s.bus mapping has to align with that of the BGC and vice versa.

In any case here is a brief video of my aerial BGC test for stability..... only using a Hero GoPro3+ but it is a start.....
[video]http://forum.basecamelectronics.com/index.php?p=/discussion/1019/32bit-2-41b4-aerial-stability-test-with-gopro3-#Item_1[/video]

Below yaw. I messaged my supplier who said that using fc inputs wouldn't offer any additional benefits over 2 imus.
Using a gh3 with 5206 motors. Stability is fine - horizon still wanders from time to time. I've done advanced calib on both imus and tried just about every gyro trust setting. Still wanders like 8 bit on 1 imu.

 

[tombrown1]

Huge horizon issue at the very start of your video. Also some pretty severe pitch lag.

 

[gtranquilla]

Tom...Good2know... I will work on that.... Thanks4feedback.

 

[tombrown1]

Get the p as high as you can get away with on pitch.

 

[SMP]

Concur, running crazy high P and D values and ridiculously low I values. Like 50, 0.1, 45 near max power. To date the only value I've seen out of the 32 bit boards is that the boards seem more stable. Most of the 8 bits have had strange heli BS (do the same thing over and over till it works rubbish) whereas so far the 32's seem to accept software inputs without fanfare. That alone is worth the price of entry. Now that they are down to 170 for the 32s and 150 for the 8s the point is a bit moot.

The narrow tuning range is coming from input from the RCG thread. Frankly seems about the same, the trick with the 8 bits is knowing what FW made what changes to PID values.

 

[gtranquilla]

I had too many issues with extending the 8 bit to allow for the 3rd, i.e., Yaw access board especially with the board layout and wiring..... made for a very messy job so I moved on to the 32bit.
The 32 bit allows for the 2nd IMU which, I believe, the 8 bit does not.

It also has a significant future migration path such that wireless bluetooth can be added and with Java.... potential apps for IPhone etc.
Also the s.bus connectivity might open the door for access to the FC magnetometers and digital compass data etc.

But for all the extra bells and whistles, the 1st priority has to remain.... getting the PID tuning for each axis nailed down for all camera weights and fixing the yaw axis heading with a Cinestar landing gear BGC combo is somewhat challenging since landing gear cannot touch the ground when setting the heading etc.

 

[RyanMcCrae]

Concur, running crazy high P and D values and ridiculously low I values. Like 50, 0.1, 45 near max power. To date the only value I've seen out of the 32 bit boards is that the boards seem more stable. Most of the 8 bits have had strange heli BS (do the same thing over and over till it works rubbish) whereas so far the 32's seem to accept software inputs without fanfare. That alone is worth the price of entry. Now that they are down to 170 for the 32s and 150 for the 8s the point is a bit moot.

The narrow tuning range is coming from input from the RCG thread. Frankly seems about the same, the trick with the 8 bits is knowing what FW made what changes to PID values.

Im just starting to tune my 32 bit board, are you saying its better to have a low I value? and high P and D?