HontaiTec Quadcopters (HT F801, HT F803,...)

Yes, yes, I confirm, channels 5, 19 and 28 at every sample
I will compile the build with latest code in a while

Great job Hexfet!!!

It's working !!!!




Test build:
dl.dropboxusercontent.com/u/14941708/dev...n-devo7e-Unknown.zip

Nice! Please try a few random fixed id values (and 256) to spot check the algorithm. The txid is still tied directly to the fixed id in this build.

Would you like to revisit the driven trims and see if there's an effect on pitch and roll? Durete, probably would be quickest if you could do the same code changes you did with the rudder channel to check the trim direction on roll and pitch. Then see if they have the desired effect on the copter. Some channel captures at 8MHz sample rate or higher would be nice to confirm the previous ones that had the shifted data.

There's still the mystery of the yaw drift, which seemed to be present even in the build that sent the exact same center values as the stock tx.

Y'all are doing the hard work!

Yep, I tested before my previous post using some random Fixed id's, including 256 . Not problem at all

I will assembly now my quadcopter, remove the logic analyzer from the RX and attach again to stock TX to capture Hi Res captures (16mhz is ok?) from sticks, since the functions are working perfect.
Later will start to compile a build including the driving trims to figure out the right direction.

Could be related to previous faulty captures (shifted data) the yaw drift issue? Our yaw is perfectly stable with stock TX and Greenfly and me have drift to one side using Deviation.

We all are doing the hard work!

The higher sample rate is only needed for the receiver captures. Looks like the tx SPI bus clock is about 650kHz. No worries if you've already re-assembled - even the shifted captures indicate we're sending the right data and it's being received correctly. No need for any more tx captures

I'd suggest going ahead with the roll and pitch tests now. After we settle that we can revisit the drift - maybe start with retrying forcing the same center values as the stock tx.

mildly interesting: the unused first three bytes of the txid in ascii are "LK:". Developer's initials? "Lookup Key"?

Since Durete is going to work on testing the roll and pitch, I had a couple of questions myself. I am trying to get set up to pull your latest changes and build what Durete does.

1. I have installed and checked all of the requirement for building on my (Windows) PC.
2. I have confirmed my environment by downloading a zip of the latest branch under bitbucket.org/deviationtx/deviation and building devo7e.dfu with no errors.
3. I get make errors when I do the same with bitbucket.org/hexfet/deviation (See attached screenshot)

Any ideas what I am doing wrong?

Thanks.

Not sure what code you got in step 2 but it must be somewhat older. It's failing because the current default branch is too large for the 7e when built with the 4.9 toolchain. You'll need to install the 4.8 version of the ARM toolset and build with that. I don't know how to do that on Windows.

I must have missed that little detail about version 4.8. I think I can just uninstall the 4.9 and then install the 4.8. I knew I should have done this on a virtual machine.

OK, I am not a bitbucket user so getting a copy of the latest is a mystery to me. I was planning on learning mercurial later when I might actually have something to contribute... but for now... I just want to get the latest source to build when you check in your changes. Like Durete.

I guess I could pose many of my questions to him as well.

Anyway, thanks for any assistance you can provide.

@goebish ---- Thanks!

---

On Windows I've used TortoiseHg before. Easiest way to start would be to clone my repository ( bitbucket.org/hexfet/deviation ). You'll need a bitbucket account I think. Use TortoiseHg to update to the hontai branch, which sets the directory contents to that changeset. Then make any changes you want and build.

Bitbucket has a good intro to mercurial.

Thanks everyone... I'm am able to build the hontai branch of hexfet's repo. I still have some learning to do, but it is a start. It's fun!

Great team job HexFet & Durete

SeByDocKy wrote: Great team job HexFet & Durete

... and Greenfly

Thanks!


I will start to test pitch/roll trims packets when return home from work.

@Hexfet.
I have a question about your script posted some pages ago (spi_format.rb).
According the file extension, seems to be a Ruby Language file.
Should I install the Ruby environmet to use?
Can I use from my DeviationTx environment?

Thanks!

Yes, you'll need Ruby . Should work with any version 1.9.3 or later. If it's in your path you can run it anywhere.

Filter just the data packets with the -m option: -m A0 for tx captures, -m 61 for rx. Output file is in csv format. For example:
ruby path/to/spi_format.rb -m A0 "input csv filename" "output filename"

Thanks, I will take a look

OK, what kind of roll and pitch testing did we need to do? Is that something Durete was just going to do with the code base?

BTW: Until I get familiar with the source, can you tell me which file(s) you are working in for all of this testing?. I'm sure it must be evident somehow, but for this old Microsoft developer I have not learned enough yet.

Thanks

Ok, just checked the trims packet. The right order seems to be:

And checked the trim captures:

According the captures, every channel is starting to one side from 0 to 20. OK.
But the other side, is starting reversed. At first trim pulsation the trim value starts from FF and finish at DF.
I don't know if this could be the problem, since my skills are very limited, but when you reach almost the stick limit at every channel (only in one side), the quadcopter suddenly change to the other side.

I recorded a video trying to show you the behaviour.

@Greenfly, this build is compiled with latest version from Hexfet's code (at hontai_nrf24l01.c file), with only this changes:

dl.dropboxusercontent.com/u/14941708/dev...n-devo7e-Unknown.zip

Please, try to explain with your good English the behaviour