congratulations!
one open issue, if I’m not mistaken, is spektrum satellite support on pixracer. Is there a time line which could be mentioned?
thx
Thanks a lot … Good work guys !!!
@olliw42,
Thanks for the reminder. I think it will actually take less than an hour or two to fix the issue but we’ve been stuck because nobody has the right combination of equipment (pixracer + spektrum with >8 channel). I attempted to buy the equipment but sadly it arrived (after 4 weeks) broken or I broke it within 5minutes of getting it (broken pins).
Tridge tells me that what he needs is a file which includes the string of characters coming out of the receiver so he can test the parser.
Tomorrow I’ll try and test again with my equipment…
thx for the quick response
I would be perfectly willing to help out with testing, if I can.
I do have now a pixracer (R12, with spektrum resistor-removal mod) and use a spektrum satellite. I though do have a 6 channel transmitter (old DX6i), but for this setup I too get incorrect signals. I can’t tell if it’s the same issue you guys are talking about, but it deems me natural to assume so. Anyway, if that should be news: Also with a 6 channel transmitter there are issues.
I think I should be able to generate the requested string of characters, but - honestly - I’m somewhat surprised that it is the parser which is suspected. I mean, the parser was working before, and it should be easy to see if something has been changed here, so I was assuming that it must be something much nastier than that.
I actually looked in the code, but I didn’t got far. The processing of the spektrum signal seems to go through all levels from the very bottom to the top, which I couldn’t comprehend. If you would have a pointer to where you suspect the issue, I would be happy to have a look at it.
Cheers, Olli
1 Like
ähm, recorded spektrum streams but used 115200 baud, for reason which totally confuse me now, have first to sort that out …
thus deleted
EDIT II: to make things most confusing I checked:
paparazzi, cleanflight, px4 (as of 2014, that’s what I had on disk) are using 115200, I do use 115200 in the STorM32 (seemed to work)
a spektrum doc says 125000, but also “For those UARTs which are not capable of that speed, they will also work at the more-standard 115200bps.”, whatever this is supposed to mean. In an 8years old blog of mine on rcline I concluded 125000. Also TheSteve on rcgroups. ???
I guess I’m not of much help here. Sorry.
Seems very good but perhaps a caution for tricopter flyers, my CH7 (yaw servo) has to be reversed (1) for the servo direction to control the tail correctly, seems the new firmware set it back to the default which is 0 and this could catch some out. (note: due to the name changes this is not listed if you check by doing a parameter compare)
Yaw PID’s seem about 30% more sensitive and roll/pitch about 20% more sensitive (noticed a mild roll oscillation while in ground effect which wasn’t there in v3.4.x), Is this expected?
1 Like
Hi @olliw42,
Re the spektrum woes, I’m all a bit helpless in this area. I’ve asked Tridge if he can step in here and help us out.
The fact that you’ve seen it with a 6 channel setup is new and perhaps quite important info.
Maybe a good first step is to rule out the parser as the issue. So if you can post a file which is the output of the receiver I’m pretty sure Tridge can run that through he parser and if nothing bad happens we know it’s not the parser.
the files I’ve deleted in the above post are still online. Here the link again: www.olliw.eu/drop/apm/ac350-spektrumtest.zip.
I’m still puzzled by 115200 over 125000. Many projects seem to use 115200, and this successfully, while I think evidence is compelling that it should be 125000. The above files were recorded with 115200, so, if Tridge thinks that’s ok, he could use them right away (I suspect that 115200 or 125000 doesn’t yield different byte stream). I’ll try to record also with 125000 in few days.
I was following the pixracer-spektrum discussion, but I didn’t realize that this was specific to some setup(s). Sorry for not having reported my issues sooner, in hindsight I should have.
thx, Olli
edit: if you would have a pointer to the parser code, I would be happy to look at it too
Just want to say that 3.5 is working great for me and I really appreciate the developers efforts. I added a second GPS to take advantage of blended GPS and it is working flawlessly. Also performed a auto tune from position hold last night and it was amazing. I will have to post the telemetry data, but I was just so happy to not have to touch the controls because of it not drifting off.
Thanks again.
2 Likes
@olliw42,
Tridge has a potential fix for the DSMx issue. It appears that, as you suspected, it was quite a low-level problem. In particular we’re using direct memory access a lot more in AC3.5 (and higher) to improve performance. Here’s the two PRs together that should fix the problem:
I’ll produce an AC3.5.0 based firmware no later than Monday and then people can give it a try.
FANTASTIC
I’ll test ASAP
just for my curiosity, since I could not yet find that info (I’m a nuttx illiterate), are you using 115200 or 125000 bauds in reading the spektrum signal?
THX so much,
Olli
Olli,
Here’s the link to a zip file containing 3 binaries (v2 = Pixhawk, v3 = Pixhawk2, v3 = pixracer).
Tridge has lightly bench tested it with a Pixracer and Spektrum receiver. I’ve test flown it on a regular Pixhawk (with futaba receiver) and it seems OK.
Think you could give it a try? If it seems ok we will release it as AC3.5.1-rc1 in the very near future.
I sure will test it
thx so much, guys
my flight controller horizon is up and down i tried to calibrate to fix but its not working what should i do?
I tested the zip you provided using the very same procedure as before two times for more than 10 min each, and I did not get any indication of a problem
I can’t test fly the code (don’t have no vehicle yet for the pixracer)
but as much as I can see it looks
THX !!
1 Like
Olliw,
Great, thanks very much!
I’ve test flown it (and so has Peter Barker) so I’ll do another test flight and then push out for beta testing.
I am looking for any word on the I2C2 issues, specifically the fact that we can not drive an SF/11 C rangefinder on the external I2C bus (aka I2C2) of the PIxhawk 2. I know you can use if if you use the serial port but that is taken. Also, there is an issue with using a 2nd GPS unit with the Pixhawk 2 that is also firmware related. Any love on these issues by chance? (I did not see anything posted on the changes for 3.5).
Have just been alerted by another Pixhack owner that in AC 3.5.0 the second onboard compass is no longer recognised whereas it was fine in AC 3.4.6.In looking back over a few logs it seems this is correct.Despite disabling the third compass it was recognised as can be seen in the parameters.This is no biggy for me as two compasses are plenty but it does mean something went wrong in the transition to 3.5.0. and it no longer sees this bit of hardware.
CUAV Pixhack V3
**AC 3,4,6 **
PARM, 52446178, COMPASS_DEV_ID, 73225
PARM, 52446206, COMPASS_DEV_ID2, 131874
PARM, 52446274, COMPASS_DEV_ID3, 263178
AC3.5.0 with different primary compass.
PARM, 248385139, COMPASS_DEV_ID, 466441
PARM, 248385174, COMPASS_DEV_ID2, 131874
PARM, 248385207, COMPASS_DEV_ID3, 0
This also showed up in my recent calibration video with only two green bars active during it.
1 Like
Chad,
I’m sure we will allow the lightware to be used on the Pixhawk’s 2nd I2C bus. It’s not a large change but I can’t immediately guarantee when we will enable that. The issue has been raised here. I suspect that will go into an AC3.5.x point release but I just can’t promise it immediately.
I’m not aware of any issues using the 2nd GPS on the PH2… I’ll have a look around but if you have a link to an issue…