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).
YMMW
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.
Any resolution or new info on “bad logging” with ChibiOS issue ? @tridge
I have experienced the same behaviors described in this and other “bad logging” threads with rover on ChibiOS and not on NutOS with different pixhawks and different SD cards. I also reported a hang in ChibiOS on some 2.4.8 pixhawks that did not occur on NutOS here (Pixhawk 2.4.8 hangs with solid yellow I/O Bootloader Mode LED) that also remains unresolved.
Seems likely the combination of lower quality pixhawk h/w with faster i/o in ChibiOS (relative to NutOS) may explain these anomolies, but sure would be great to have a fix or workaround, or minimally, guidance on h/w known to work reliably.
I tracked this down as far as finding it comes from the frsky passthru code, and I got lost after that. Either the test takes place before a log is started, or it should not be an error at all. The code was confusing. I vote we remove the check from passthru, since it really does not belong there anyway. I believe the same checks are done after a log is started.
This is one of the oldest unresolved major issues, and I can’t understand why it’s still dogging our steps. I’ve had it with old and new controllers, $100 and $50 units, and I’m really tired of it. This could drive me back to my “Trees”.
Latest:
Brand new good quality (I think) pixhawk 1, tried all the stuff. four different cards, all formatted and good quality and work with other equipment. “Bad logging” for a while. Change cards back to original one, works—for three logs, then "bad logging comes back. Two GPSs, 10 and 14 sats, outdoors, same with other cards. Tridge, --someone–can we get this fixed, or is it an unfixable hardware defect, and no one wants to say it?
This may seem random, but which EKF are you running with? I have a vague memory of a similar issue 15 months ago where switching to EKF2 (instead of EKF3) fixed the issue.
Went back to default params, unplugged servos, set all logging params to no logging positions, reinitialized both compasses and did the compass dance, fired up outdoors. That eliminated the “bad AHRS” message, and the horizon is steadier. No dataflash logs, as expected, but no nasty messages about “bad logging”… Now I’ll reinitialize logging a bit at a time, and see what happens. Stay tuned.
EDIT: GOT IT!!! He says, —with heart in mouth.
With both compasses running and swung, "Bad AHRS is gone, and “Bad logging” is also gone.
I reset parameters to largest amount of logging, and most rigorous GPS parameters, and all is well. mLogs produced are typical and seem OK.
The wiki says a compass is not only not needed with a fixed wing, but is not advised. Boy, is this a bad bit of advice!
ONCE I’M SURE THIS IS REAL, I’ll cross post it to the community- pixhawk and arduplane x.9 so no other not-so swift user has to go through this! reply.
I dare to think I’ve got it.
Someone smarter than I am needs to check this out. I’m a fair troubleshooter but not a coder.
Came close to the very expensive bonfire on this one!