Jump to content

Attention: RC-CAM.com will be closing down August 2021.

The RC-Cam.com forum was the very first online community dedicated to the advancement of wireless video cameras on radio controlled (R/C) models. This is now called "FPV" (First Person View). We are proud of the contributions that our members have made to the FPV hobby.

We've seen significant changes over the last twenty years. Initially there were a lot of eager R/C hobbyist that built their own video systems. Allowing these creative individuals to share their work was the purpose of this site. Now the FPV market is flooded with low cost systems; Sadly DiY FPV video projects are now rarely discussed.

RC-CAM.com (main site and forum) will be closing down August 2021. This is being announced now (March 2021) so that everyone has time to download any information that is important to them. After the site is shutdown the information will no longer be available here.

We appreciate every member's involvement with advancing the FPV hobby. It is indeed sad to say goodbye to all our online friends. Be safe and stay healthy.



Recommended Posts

It is a good news have one microcontroled conversor....

You need to ask Mr. RC-Cam but I think the PIC is only for the lost signal control and not for the entire PWM-to-PPM conversion. I could be wrong though, it is just a guess.

Mr. RC-Cam: I never asked any details about the new version. Is the new one all PIC bassed???

Richard

Link to post
Share on other sites
  • Replies 355
  • Created
  • Last Reply

Top Posters In This Topic

The microcontroller is only used to detect the DX7 failsafe state, which will rely on programming the Rx to send an exaggerated low throttle servo pulse during failsafe. This is similar to the trick that is used to make the LoMA lost model finder work on the AR7000 (as described here: http://www.rc-cam.com/forum/index.php?showtopic=2187)

If you ask me, the preferred way to reorder the PPM channel sequence is to do it inside the Quadrocopter host controller (via a firmware revision). Re-ordering the channels with external trickery is not something I have fond feelings for (it is more complicated than it sounds, honest). Frankly, the best thing to do is to convince the Quadrocopter designers to include a servo order profile that is compatible with the goofy sequence that the Spektrum uses. I have no idea on how well they respond to such suggestions, but it wouldn't hurt to beg them to add this to their next release.

Link to post
Share on other sites

i was talking with wolferl and he told me that in this weekend he will get an AR7000.... maybe a ligth in the end of the tunel for this.... do you dont ha a topic that are hacking the AR7000?

But i need a this working in hte next week... so i thing i gona buy a used radio for now... but after i will got it flyng with the AR7000.

Link to post
Share on other sites
i was talking with wolferl and he told me that in this weekend he will get an AR7000

It is nice to hear he will help you out. Please keep us posted on what he creates for the DX7.

do you don't ha a topic that are hacking the AR7000?

There were some discussions on another forum about making internal hacks to the AR7000 that would allow a microcontroller to read its raw data stream. That would allow channel reordering during the translation to servo-PPM. However, I don't believe anyone has produced a design to do that. So, for now, the circuit discussed here is the best solution.

Link to post
Share on other sites
It is nice to hear he will help you out. Please keep us posted on what he creates for the DX7.

There were some discussions on another forum about making internal hacks to the AR7000 that would allow a microcontroller to read its raw data stream. That would allow channel reordering during the translation to servo-PPM. However, I don't believe anyone has produced a design to do that. So, for now, the circuit discussed here is the best solution.

There are actually one or two people who have done that. The satelite receivers are industry standard and have all the firmware to control their connection. They output a simple serial data stream. That can be read with a microprocessor. At least one person has used two such satelite receivers to create his own "Spektrum" receiver but output a single PPM stream. See: http://www.rc-cam.com/forum/index.php?show...0&start=140

The Mikrokoper FC is actually very flexible in channel sequence. It essentilly just accepts the channels in whatever sequence they come in. The user then defines which channel is what. Doesn't get much more flexible than that.

Little update from my side: I have had little one indoor flighttest, using the MySmartUSB interface onto the computer in motor-test mode, with APMk (Aerial Photography MultiKopter) nr 1, which I finished assembling earlier this week. Thing was very stable hovering about 50cm above ground and just lightly restrained with my hand as throttle control through the MKTool is not very accurate. Immediate counterreaction at any attempt to move it. Now this was indoor in my overfilled study with just cm around the craft and all sorts of furniture. I could actually feel the turbulence with my hand, but very little effect on the craft.

Finished assembly and basic wiring on APMk nr 2 and nr 3 this evening. Richard was kind enough to make several of his PCBs for the v2 PWM2PPM converter for me. First one of those is almost wired up. Will finish that tomorrow, and also do two more. So sometime tomorrow I should have 3 APMk's based on the same frame design but with different motors (Turnigy 2213, Turnigy 2217, and HYX 3542) and thus RTF weight (estimated from 1300 to 2100 including camera mount and camera) ready for testflight. Finally !!!

Edited by Arthur P.
Link to post
Share on other sites

-AT-Mr Cam-Man, Very nice little PCB. And interesting solution to the failsafe issue. I-ve been thinking about the latter as well. I think I would rather see that solved in the FC firmware as almost all MK's have an airpressure sensor, all have gyro's and accelerometers, and then some have compass and GPS. The changes needed to the firmware, from a logical perspective, would probably have to do the following:

on first throttle up over x% get airpressure value as zero altitude value (could be a handstart, but we can correct for that) and set flightflag

if no ppm signal (receiver without failsafe) or if no change in ppm signal for x seconds (receiver must be in failsafe mode) then

if flightflag then

if altitude close to or below zero, motors on, and sensors indicate movement cut throttle to 20% (controled drop for the last couple of cm)

if altitude close to or below zero, motors on, and sensors indicate no significant movement, turn motors off and set flightflag to NO (avoids any throttle activity until there is signal again)

if altitude >> zero, motors on, and sensors indicate movement, reduce throttle and check decent rate for adjusting throttle to reach predetermined decent rate until altitude close to or below zero

if alttude >> zero, motors on, and sensors incidate little or no movement, then we must have landed on a roof or in a tree or something, so just cut the throttle and turn flightflag to NO.

In case there was a GPS reciever this would become more complex as you could then have the option of return to takeoff point (and hopefully ability to define a safe altitude at which to fly backto takeoff (you don't want it to come in at 5m if you're in between 20 meter trees), or maybe even to the nearest predefined safe landing point.

Link to post
Share on other sites
Jim was kind enough to make several of his PCBs for the v2 PWM2PPM converter for me.

Is this V2 the same V2 circuit that evolved here, or something else? If it is something else, can you offer a link to Jim's (?) project?

... interesting solution to the failsafe issue. I've been thinking about the latter as well. I think I would rather see that solved in the FC firmware as almost all MK's have an airpressure sensor, all have gyro's and accelerometers, and then some have compass and GPS.

Just about every problem has several opportunity solutions. I'm just trying to solve this one with some simple technology I can nail down with the e-hammers I have on the tool bench. First one to the finish line gets the beer. :)

Link to post
Share on other sites
  • 2 weeks later...

Well today was "the" big day, the first outdoor testflights. Conditions were "near perfect": 8 degrees Centigrade, heavy overcast, and winds gusting to 45km/h (about 30 mph) :P But in view of the good stability the machines had shown during some indoor handheld testing, I decided to just go ahead. Of course all did not go completely as planned. APMk (Aerial Photography Multikopter, but also a jab at my initials APM) nr 1 had a wrong and incompletely charged battery, so only several short hops, but still it managed the wind quite well, immediately hanging into it as soon as it got light on its feet.

APMk nr 2 had a bit of a thump after the first hop due to my twitchiness on the controls and "lost a leg". But on a bit of a little slope it was stable enough on the remaining 3 to still do some more and increasingly long "hops", even going up to about 10 meters. And with a bit more weight, even more capable of handling the gusting winds. Really amazing. B)

Only APMk nr 3 didn't make it into the air as motor nr 1 wouldn't start for some reason. :(

All three have the Spektrum AR7000 on board, with the PWM2PPM v.2 converters. Work excellently !!! Thank you !!

More pics and details here:

http://forum.mikrokopter.de/topic-1023-2.html

and here:

http://www.rcgroups.com/forums/showthread....121#post9312892

post-2251-1205008360_thumb.jpg

Edited by Arthur P.
Link to post
Share on other sites

You've got three of them! That's insane, but in a good way. :)

It's great to hear that the AR7000 PPM V2 interface is working well. I expect to spend some time next week to finish up the failsafe equipped version. The code to detect the AR7000 failsafe is written (detects exaggerated low throttle), so it's almost a done deal. Or so I hope.

osvaldoljunior: did the Quadrocopter folks ever come through with a AR7000 fix? That is, did they reorder the channels for it?

Link to post
Share on other sites
You've got three of them! That's insane, but in a good way. :)

It's great to hear that the AR7000 PPM V2 interface is working well. I expect to spend some time next week to finish up the failsafe equipped version. The code to detect the AR7000 failsafe is written (detects exaggerated low throttle), so it's almost a done deal. Or so I hope.

osvaldoljunior: did the Quadrocopter folks ever come through with a AR7000 fix? That is, did they reorder the channels for it?

Actually I have the FC ready and the parts all lined up for APMk nr 4. Got stuck with an additional one on a group order. I-m going to use that one as "experimental", i.e. for testing different frame improvements, new firmware, etc. Motors for that one initially will be Turnigy 2830 - 1050kV, so it will be a "lightweight", but may get 4 more and go for an octocopter on that testbed ;=))

The ESC on motor 1 of the heavy APMk nr 3 has me stumped. All connections are intact. The motor arms correctly with the nice Quax tones. But it isn't responding to I2C/TWI throttle commands at all. I-m considering trying to reprogram it (maybe it lost it's address??), or just convert a next TowerPro 25A ESC, and only then reprogram this failing one as a "spare".

Link to post
Share on other sites

Great to hear about your success :) Arthur, amazing they hold up to that kind of wind. WOW!!!.

If I get the chance, I will try the failsafe beta tomorrow and will report back. Hopefully I will get enough time to 'hack' it in and test it out.

Richard

Edited by brashley
Link to post
Share on other sites

AR7000 PWM-to-PPM failsafe beta test: :)

RC-Cam provided a HEX file for a PIC (12F509) that detects either a low or high exaggerated throttle pulse width (position) and then provides a low or high signal that can be used to signify a lost signal state. The process goes like this;

1) set your throttle low throw to 150%

2) bind your receiver to the TX (this sets the lost signal throttle to the low 150% value)

3) once the binding is done, reset the throttle throw to the standard 100%

4) add the PIC to the converter and hook up the Failsafe Low Output to the two CLR inputs of the HC221 (PIC pin 3, HC221 pins 3&11)

5) hook up the throttle to the PIC (pin 7)

6) add a LED to the failsafe high if you want (pin 6) [with appropriate resistor of course RC_Cam recommended a 220 ohm series resistor for std bright LED]

7) Hook up power and GND (pin 1, pin 8)

8) Add .1uF cap across V+ and GND on the PIC (needed for the PICs internal oscillator stability)

When the signal is lost, the AR7000 sets the throttle to the preset bound position (very short PWM signal) and the PIC detects this low state and then switches off the HC221s output shutting off the PPM out. Turn the TX back on and the throttle jumps to a normal range and the PIC turns the HC221 output back on and the PPM is live again.

I tested it with the MK as well and the MK started beeping (lost signal state) as soon as the PPM goes silent :D . On-Off-On-Off no problem. There is a second or two delay though (AR7000 obviously does not go into failsafe mode instantaneously, nor does the PIC code)

RC-Cam also added some changeable offsets (for high/low PWM threshold settings) that would allow some one to tweak the failsafe threshold detect levels but I did not find I needed to do that

I hacked it into my V2 board (I have been using my V1 [MK still not flying] and had not yet cabled my V2 one up so this gave me the motivation to go ahead and finish it up). I simply glued the programmed PIC on the PCB and white wired up the rest (RC_Cam suggested bending the CLR pins up on the HC221 to disconnect them from the rest of circuit and that worked great)

Richard

The Converter with PIC hacked in:

post-3782-1205193335_thumb.jpg

TX On Scope picture:

post-3782-1205193405_thumb.jpg

TX Off Scope picture:

post-3782-1205193432_thumb.jpg

Edited by brashley
Link to post
Share on other sites

brashley, that is great news. It's Miller time!

Attached are the V3 firmware files and revised schematic. The microcontroller is a Microchip PIC12F509, which is a Flash part and can be reprogrammed. Just don't change the factory calibrated OSCCAL value when you erase or program it.

If you cannot find the PIC12F509, then you can use the one-time-programmable PIC12C509 or 509A.

.

DXfs1_0.zip

post-2-1205256435_thumb.jpg

Edited by Mr.RC-Cam
Fixed schematic
Link to post
Share on other sites

For those who are actually paying attention, I mentioned that the PIC output gets hooked up the HC221 CLR Pins 3 & 10. That was incorrect :huh: ; it was actually Pins 3 & 11 (I will change my earlier post). Looking at the Function table for the HC221, the end result is about the same :P (I will get one extra pulse on the rising edge of the B input but other than that it is the same) I soldered it to the wrong pin and then documented what I soldered. You may also notice from the picture above that I did not have the cap in between V+ and GND, I have also now added that as well. I also now tacked down the white wires with a dab of glue to hold them in place. A new picture is included in this post

Richard

Updated Picture of Converter:

post-3782-1205209958_thumb.jpg

Edited by brashley
Link to post
Share on other sites

After a lot of work to do i finally found time to go further with my own Spektrum RX PPM solution.

My solution is a Microcontroller (to not overwrite the original chip) or Firmware replacement (the isp pins are available on the AR7000 PCB) for the Spektrum AR7000 with a lot of extended features compared to the original AR7000.

The main features are, PPM Sum. Output on the BAT connector, support for a second satelite receiver (3 receivers at all), configuration for "hold only", "failsafe after hold" and "no failsave at all", the last one is important for the MK to use their own failsafe and LMA features. Configuration is simply done by putting the bind jumper onto different Channel pins or the Bat connector for entering binding.

In the meantime i've also done a own small PCB for it to not always break up the AR7000 case when in need for a RX. My own PCB is fully Controller pin compatible with the AR7000 PCB but striped down the one single output (AR7000 Bat connector) where the PPM sum Signal is present.

Here is a picture of my own receiver Board: (simple one side PCB version)

http://www.chiptech.de/pub/IMGP0699.JPG

here with the satelites connected:

http://www.chiptech.de/pub/IMGP0698.JPG

And here is a Video where you can see the receiver board in operation including binding process and so on.

http://www.chiptech.de/pub/IMGP0697.AVI (Attention about 70Mbyte Video File)

A blue LEDs is signaling the Satelite receiver states, by showing how many expected receivers are delivering valid datas.

How many and what receiver is expected depens how many and what receiver where present with valid datas during the binding process.

At the moment i'am implementing the possibility to be able to connect the "Spektrum information display" to show lost frames and fadings betweend the receivers.

Also i've already investigatet the signals and different behaviour when using AR9000 with DX7 and using AR7000 with DM8 and DM7, so i can say that it is possible to get up to 9 channels output on PPM Sum. line when using DM9 or at least 8 when using DM8. Not easy but possible.

Best regards,

Walter

Edited by LabMaster
Link to post
Share on other sites

Very ingenous and very impressive Richard and Mr Cam-Man !! Actually, I believe the 2 second delay is in part due to the FC settings. At least in v0.68d the default delay in the MKTool is 20x 0.1 seconds :)

I converted 8 new TowerPro 25A/2's on Sunday afternoon, am back to just quickly soldering the programming wires to the right legs and then removing them. Those are actually so easy, that it takes about as long as the multiple attempts needed to position the clay programming adapter. Overall time for conversions is down to about 45 minutes per ESC from starting to put on the battery connnectors to finishing up the new heat-shrink with in between connecting the programming wires, reprogramming for the correct motor, removing the porgramming wires, drilling through the existing incorrect route, checking correct resistance, rerouting one port, rechecking correct resistances, making an 3-wire TWI servotype connector, going from servo wire to wire-wrap wire with heatshrink isolation, connecting the SDA/SCL/GND lines, shortening the normal PWM connector wires so that the plug can still be used to power LEDs off of the BEC, testing the ESC over the TWI interface, putting a few dabs of epoxy over the new connections to fixate and isolate them, heat-shrinking the ESC back up, and retesting one final time. Not bad, looking at the number of steps :D

I also modified the landing gear on all three APMk's by putting 3 6mm carbon rod braces horizontally between the legs about 5cm off the ground (along the sides and behind the camera, putting on carbon 6mm carbon rod "skids" on the bottom of the legs, and wrapping "pool-noodle" type pipe isolation around the skids with the rear 15cm coloured red with marker pen. Connections are made from 6cm pieces of 8mm plastic tubing with a small hole cut in the side halfway in the length (just bend the tube back on itsself and cut off a small corner). Adds just a few grams and has tremendously stiffened the landing gear with better distribution of forces over all four legs. I-ve testdropped the heavy APMk 3 (about 2 kg with battery) on the landing gear from about 20cm, no problem. And I think the skids with the rear 15 cms being red, will help with orientation.

I also modified the camera mounts by putting a little block of wood below the gimbal ring so that it only swivels sideways. The FC can control the tilt correction very nicely, so no need to have gravity do that. On less axis of free uncontroled swinging ;)

Edited by Arthur P.
Link to post
Share on other sites

In case it matters:

The PIC includes some debouncing code before entering or exiting the failsafe state. It is about one second and is suppose to be a feature rather than a bad thing. But you know, one man's software feature is anothers bug, as I was recently reminded while customizing some PanCam project firmware. :)

The debouncing was included because the PIC may find uses in other applications, including legacy PPM Rx installations. Basically, I'm just trying to get more mileage out of the coding efforts. Long story short, the PIC's failsafe analysis adds to the existing AR7000 and the MK failsafe detection delays.

Link to post
Share on other sites

I finally had a chance to test my V3 Spektrum PPM board today. I don't have a DX7 or MK, so I simulated it all with a DX6 and a o-scope. Everything worked according to plan, including the failsafe feature. Success!

FWIW, the failsafe decoder on this version is a PIC10F series microcontroller. These are packaged in a tiny SOT-23 size SMD body. Below is a photo of the bottom side of the PCB where the PIC is located. To help appreciate its tiny size, the nearby components are 0805. That's one small microcontroller!

post-2-1205377137_thumb.jpg

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...