Hi, folks, I’m a new user, and new flyer, working on my first F550 hex clone with Pixhawk (white case), ArduCopter 3.6.1 Hexa. I’ve been bashing my head against the bench for the last several days chasing down a bad logging error on pre-arm with an occasional accompanying “No I/O thread heartbeat” message. I had been disabling it for testing until it was my last configuration error (I had bigger fish to fry, errorwise). I tried several SD chips that work in other devices, and bought a couple brand new ones tonight. None of those made a lick of difference, nor did any change I made to the the logging bitmask or logging backend settings. In desperation I decided to flash the firmware again to the pixhawk, and during the process accidentally clicked no on “Upload ChibiOS”. The firmware completed it’s flash, and I figured I’d try it out anyway. Started it up, and this time no logging warning. Armed up, throttles go, and we’re “flying” on the bench with no props. Can someone correct me if I am wrong but I believe what I did by accidentally denying ChibiOS was to load NuttX to the pixhawk? If that’s what I’ve done, it seems to have solved an issue plaguing me for the last three days. I powered everything down and pulled the card, and sure enough, I’ve got logs of my stationary flight. Have others run into this issue between ChibiOS and NuttX? In searching causes for this it seems like everyone says “try a new SD chip” and that works.
Coming back to this again, I had similar results with loading up 3.6.2 with ChibiOS vs NuttX. I get bad logging on ChibiOS and I’m logging fine on NuttX. I’m at a loss to find the issue. I’m on a White case Pixhawk “2.4.8”
I confirm this happens, also with Copter 3.6.3 final dated 04-Dec-2018.
Among several controllers, I have a Micro Pix which only booted reliably and fully (and could fly) in ChiBios with two particular µSD no name cards (1GB and 2GB) in FAT, refusing to work with genuine cards (Kingston, SanDisk) and other no name cards of several sizes, and with all of them it boots fully all times in NuttX. Messages heard or seen in ChiBios are “Bad logging” or “No io thread heartbit”.
Moreover, of three 1GB µSD no name cards, externally identical, it works with just one of them, which shows more capacity:
This Micro Pix is chinese. I ordered two, and one of them is particularily critical; however, it seems that with those two particular µSD no name cards (1GB and 2GB) in FAT it boots completely all times. I haven’t tried those two in FAT32, but I tried this in other small ones and it didn’t work.
Other controllers I have don’t boot completely at times.
It is surprising that this is rarely reported. In ChiBios, switching to a genuine card, changing FAT<>FAT32, or changing LOG_FILE_BUFSIZE doesn’t work as far as I have seen. In NuttX, no problem.
Not want to bash, but the “white” pixhawk clones are the worst possible quality controllers. It is possible that all the shortcuts that they made in create that board cause problems with faster chibios writing… I have some of them at home will try tonight.
This is the Micro Pix I refer to. It uses 1mm pitch connectors.
As documented (I have not opened it): STM32F427, L3GD20H, LSM303D, MPU6000, MS6511.
Are there any solutions / workarounds to this issue. Nearly half my aircraft have the “white” pixhawks.
(I’m running 3.10.0 for the relay controls on one plane the others I’ve rolled back to nuttx.)
Edit: Turned out i was using a class 6 card, tried a class 10 and all good now
Just to add my two cents, I have a Banggood 2.4.8 that gave me bad logging error with ChibiOS, went back to NuttX and that fixed the problems.
There’s two or three threads on this issue on the discuss forum. It is a problem in ChibiOS, has nothing to do with the controller or SD card, tridge is working on it to try to identify what is causing it.
There is no such thing as a “pixhawk clone”. The PX4-v2/PX4-v3 design is open source hardware. They are built by a variety of manufacturers and the color of the case has nothing to do with the quality of the unit. Most of the 2.4.8’s are actually an updated design that can run the v3 firmware, as they do not have the STM32 bug that limited flash to 1MB.
Let me rephrase, the white ones sold on Chinese sites are a very bad quality, budget implementation of the open source Pixhawk design. With a lot’s of shortcuts, omitted protections and low quality components.
(Usually these type of products are called clones, but indeed, if it based on the open source it is an “implementation”) On a nutshell it’s crap, and should not be trusted.
Btw, the only difference between V2 and V3 is the revision number of the used STM32 processor. No change in the circuitry.
Frankly, I’ve flown several of those white 2.4.8’s hundreds of hours and never had a problem with any of them. I still use a couple of them for test boards for testing builds and code. Still fly one on a Trex 600, and another one on a Trex 700 Nitro helicopter.
Just to make the confusion complete, there are different versions of „white“ 2.4.8 from various sources.
The ones with purple PCB and MS5611 baro, and the ones with MS5607 baro (and really poor soldering quality).
I thrown our a bunch of those because they needed recalibration below 15 celsius. The acc/gyros were crap in them.
Indeed, I don’t know about that. But the ones I’ve had are good units and have long outlasted the 3DR 2.4.6’s I had, both of which died within a year. And by that time 3DR had thrown in the towel on them. Regardless, this issue has nothing to do with the controller. It is a known issue in ChibiOS and tridge is working on it. I’ve experienced it with v3 2.4.8, Pixhawk2 (also v3), CUAV V5 and CUAV v3 running ChibiOS. The issue is random, you can fly with it and nothing bad happens other than getting a 4KB log file with nothing in it. If you reboot when the GCS notifies of “bad logging” it will normally restart and log ok. tridge has tried a couple different things, hasn’t nailed down the exact cause yet.