Taking the plunge - Paparazzi style

[vau]

That's it, I'm going to order a pre-built Tiny 2.11 and thermopiles and build a paparazzi platform.

Not in line with the original plan but it seems like it works, it's available (pre-built) and it can be customised. I see it as a pilot study at this stage.

I will keep a log running here from delivery of the goods to first flight.

[AntonK]

AWESOME! If you need any help remember that the wiki is your friend, and typically someone is in the IRC channel that can help. Good luck!

Anton

[vau]

Well after that brief interlude I am glad to say the plan continues. ;)

However the Tiny has been swapped out for a TWOG with an LEA-5H with active Sarantel. Datalink is a pair of older Maxstreams. I intend pairing this lot up with Thomas Scherrer's LRS TX/RX.

The TWOG and GPS is on the way from CheBuzz (I got the full TWOG kit minus the RF) and I'm hoping that will arrive in the next day or two so I can get Paparazzi up and running on the bench prior to being deposited into my EZ*.

I've been playing with the GCS recently and I think I've got the hang of it.

I'll post as I go......through the good times and the bad times.

[vau]

This is what I am thinking so far with regard to loayout of components within my virgin Easystar. I'll worry about cog balancing afterwards (i can always move the lipo) but here are some key points - all subject to change based on testing:

1) 1 battery for everything - probably a 2s3300 lipo, no smaller
2) Outrunner will be fitted for bigger prop - this will largely free up the stock motor space for my Ublox GPS and antenna
3) The LRS Rx (http://webx.dk/rc/uhf-link3/uhf-link3.htm) is at least 15cm away from thew 900Mhz modem and at least 22 cm away from the video TX

As soon as my kit actually arrives I will mock this layout up on a bench and see how it behaves.

cheers

u

[vau]

OK, not too painful so far.

The TWOG is running, IR sensors have been calibrated (cupboard test) and I have everything receiving OK in the GCS via a couple of maxstream modems.

I suspect there is some tweaking to be done with the modem RF link - currently the modems are configured with re-tries/acknowldegements but I am going to disable that and check performance of the telemetry aftewards.

I am thinking that it is unnecessary to seek acknowledgements from the GCS modem that telemetry has been received - it is however important that the AP acknowledgements receipt of instructions from the GCS - from what I can see though this is done at the application layer within Paparazzi.

Anyway, I'm going to get this mounted up in the Easystar whilst I'm waiting for other kit to arrive.

Photo of the testbed attached - I borrowed the stick idea from the build log over at mannberg.co.uk.

[airmcn_3]

OK, not too painful so far.

The TWOG is running, IR sensors have been calibrated (cupboard test) and I have everything receiving OK in the GCS via a couple of maxstream modems.

I suspect there is some tweaking to be done with the modem RF link - currently the modems are configured with re-tries/acknowldegements but I am going to disable that and check performance of the telemetry aftewards.

I am thinking that it is unnecessary to seek acknowledgements from the GCS modem that telemetry has been received - it is however important that the AP acknowledgements receipt of instructions from the GCS - from what I can see though this is done at the application layer within Paparazzi.

Anyway, I'm going to get this mounted up in the Easystar whilst I'm waiting for other kit to arrive.

Photo of the testbed attached - I borrowed the stick idea from the build log over at mannberg.co.uk.


Looks good! How you liking that helical GPS antenna? Do you know how many sats you’re getting inside?

I like the stick idea if you do not have an extra airframe around to tape things to.

Keep up the good work. Looking forward to the results.

Chris

[vau]

Thanks Chris, I want to try and get this in the air within a week if possible.

If I stick the GPS next to a window, I get 2-3 sats inside. I get 6-7 sats outside at ground level between nearby 2 story buildings. This is with the Maxstream transmitting close to 900 Mhz, albeit at 10mW for now.

[airmcn_3]

Thanks Chris, I want to try and get this in the air within a week if possible.

If I stick the GPS next to a window, I get 2-3 sats inside. I get 6-7 sats outside at ground level between nearby 2 story buildings. This is with the Maxstream transmitting close to 900 Mhz, albeit at 10mW for now.


Just FYI. I powered up my bird in the shop today. Covered with alloy roof. I got 9 sats right off the bat and lost 1 simulating a 60+ deg turn.

Although I think the helical antennas are neat I am not sure they are up to par with some of the patch style antennas. This is just an observation so take it with a grain of salt....

I am using a LS20031 on 5V.

Chris.

[Buzz_Lightyear]

I have the same antenna vau has and tested it out today. Under a metal roof, from cold boot, I got 3D lock with 7 satellites in 20 seconds. I have yet to lose lock while in the air. So I am very satisfied with that unit and it's helical antenna

[vau]

OK, I have been tweaking the modem configurations (using the X-CTU tool) to see how various settings affect link performance and here is the scoop.

By default both RR (retries) and MT (Multi-transmit) are enabled on the 9XStream and 9Xtend - not sure about XBees as i don't have one.

RR means each transmitted packet must be acknowldeged by the receiving modem, if it is not then the transmitting modem will resend RR times.

MT means that each transmitted packet is sent MT times in the hope that at least 1 copy of the packet will be received. No acknowledgements are required by the receiving modem.

Enabling MT on the air-side modem will significantly reduce the bandwidth of the RF link and thus significantly reduce the amount of telemetry you receive on the ground as follows: MT=1 leads to approx 30% drop in bandwidth, MT=2 leads to a 50% drop and MT=3 leads to approx 60% drop in bandwidth.

NOTE: By default these modems come with MT=3!

I have disabled both MT & RR for the air-side modem as I would rather have the next telemetry packet than have the modem trying to re-send me stale telemetry data which wasn't correctly received the first time.

I leave RR enabled on the ground modem as it is important that ground>air commands are successfully received. I may use MT instead of RR but I'll worry about that later.

Using a 9600 transparent link (not API mode) with MT and RR turned off air-side I get approx 23 messages/second (approx 500 bytes/second) using the default.xml Telemetry configuration file. :)

With MT turned on airside (out of the box configuration) I was getting about 9 messages/second at around 200 bytes/second. :mad:

I am still having problems trying to send commands from the GCS to the airside modem but this is a GCS software issue rather than the modems. Any pointers on that '1 way telemetry' issues would be greatly appreciated. :confused:

EDIT : i 'solved' the one way comms issue - I had updated airframe.xml makefile section to use transparent but not the xml section of the makefile...it's working now both ways just dandy. :cool:

[dmgoedde]

Just FYI. I powered up my bird in the shop today. Covered with alloy roof. I got 9 sats right off the bat and lost 1 simulating a 60+ deg turn.

Although I think the helical antennas are neat I am not sure they are up to par with some of the patch style antennas. This is just an observation so take it with a grain of salt....

I am using a LS20031 on 5V.

Chris.Maybe since vau is using new hardware, his LEAH5 GPS hasn't had time to acquire the updated ephemeris file. This could explain low # of sats in early testing, or am I not thinking right?

[vau]

I'll do some experiments with the GPS now that it is mounted with the correct orientation in the airframe. Dean could be right as I get a lock much quicker now than I did a couple of days ago. With the vertical alignment I have now (as opposed to leaving the unit lying horizontally on a table) I am getting a far more accurate posiiton with sub-4m accuracy.

I haven't actually used the UBlox tool yet to talk to the GPS, I have been relying on the Paparazzi GCS. Later today I will set up the TWOG in tunnel mode so I can speak to the GPS directly.

[vau]

OK, I compiled serial tunnel - got Ucenter talking to the GPS and did an 'assist offline' update of almanac data - I went for the 5 day file and this automatically writes the updated data to the flash in the GPS. I have no idea if this is persistent or not - will investigate further on that.

Anyway when I power up in the same inside location where I was getting 2-3 satellites the other day, I now get a fairly consistent 8/9 sats.

When I power up outside, again the same location as before (where I was getting 6-7 sats) I now also see 8/9 sats. Becasue I am surrounded by buildings I am somewhat in the shadows for any sats lower in the sky so if I were away from the buildings, I am guessing I would be seing more like 12 sats. Hot & warm starts takes a couple of seconds outside.

Major caveat here is that for the original observations I was using Paparazzi GCS to determine number of satellites which isn't ideal - the observations in this post were based on using U-center. regardless this unit gets a better & quicker lock than both my laptop GPS and my old garmin etrex.

[vau]

Ok, I've been reading a lot recently.

It seems (from reading) that it is not desirable to power the servos directly from the TWOG - partly down to noise/chatter and partly down to potential voltage spikes to the TWOG.

This got me looking at the whole power system and I've come up with a plan:

1) One battery to power everything, probably 2S 3000 mAh+.
2) 2x HS81 Servos powered directly from ESC BEC (e.g. BOTH black and red wires connected to ESC rather than TWOG)
3) A standalone UBEC to power the TWOG, Modem and Receiver.
4) The video TX straight on to the battery

Does this sound reasonable? I have attached a schematic below showing the proposed power system layout.

I was wondering if any of you gurus had any thoughts on the following questions that keep buzzing around me head?

a) Are we OK with onlythe PWM signal wire being connected between the TWOG and the servos/ESC throttle?
b) Should I also leave the servo ground wire connected to the TWOG (don't see why as common ground throughout system.)
c) Should I just connect the TWOG straight on to the battery rather than the UBEC? It could handle the voltage just fine.
d) Should I run the Video TX off the battery as I have it or is it better to run it from the UBEC with the other components?
e) Should I forget this and just keep it simple and use the TWOG to power the servos and the modem?

:confused:

I am always a little concerned about frying something too, that would be BAD :eek:

Has anyone been there and done that already?

[Buzz_Lightyear]

These are just my thought and definitely not the final say. I would love to hear what other veterans have to say about it.

a and b) as long as you have common ground (and you are absolutely sure of it) no reason to run more wires there.
c) I would say to just hook your TWOG straight the battery. It's possible to use a UBEC but then you lose your battery voltage reading. The TWOG 5V regulator is more than capable of handling your current needs for the setup you describe.
d) I don't see any problem with hooking video TX to the same battery, but I don't have any experience in that area.
e) Where you only have 2 micro servos, I think you are just fine running everything off the TWOG (except maybe video TX, again no experience). The problem came when people were using 5-6 big servos which draws too much current from the 5V regulator. As long as you keep it 2A or under, you should be just fine.

[mavacpjm71]

OK, I have been tweaking the modem configurations (using the X-CTU tool) to see how various settings affect link performance and here is the scoop.

By default both RR (retries) and MT (Multi-transmit) are enabled on the 9XStream and 9Xtend - not sure about XBees as i don't have one.

RR means each transmitted packet must be acknowldeged by the receiving modem, if it is not then the transmitting modem will resend RR times.

MT means that each transmitted packet is sent MT times in the hope that at least 1 copy of the packet will be received. No acknowledgements are required by the receiving modem.

Enabling MT on the air-side modem will significantly reduce the bandwidth of the RF link and thus significantly reduce the amount of telemetry you receive on the ground as follows: MT=1 leads to approx 30% drop in bandwidth, MT=2 leads to a 50% drop and MT=3 leads to approx 60% drop in bandwidth.

NOTE: By default these modems come with MT=3!

I have disabled both MT & RR for the air-side modem as I would rather have the next telemetry packet than have the modem trying to re-send me stale telemetry data which wasn't correctly received the first time.

I leave RR enabled on the ground modem as it is important that ground>air commands are successfully received. I may use MT instead of RR but I'll worry about that later.

Using a 9600 transparent link (not API mode) with MT and RR turned off air-side I get approx 23 messages/second (approx 500 bytes/second) using the default.xml Telemetry configuration file. :)

With MT turned on airside (out of the box configuration) I was getting about 9 messages/second at around 200 bytes/second. :mad:

I am still having problems trying to send commands from the GCS to the airside modem but this is a GCS software issue rather than the modems. Any pointers on that '1 way telemetry' issues would be greatly appreciated. :confused:

EDIT : i 'solved' the one way comms issue - I had updated airframe.xml makefile section to use transparent but not the xml section of the makefile...it's working now both ways just dandy. :cool:

I am having the one way comms too, can you elaborate a little more on the resolve. ? Would help me out immensely.

-Peter

[vau]

OK, things have gone fairly slowly recently. I have been waiting over a month for some extended Paparazzi cables [edit: they turned up this morning after a grand total of 32 days in the post!]

So I have pressed on and, where necessary, fabricated my own extended cables - I will say the picoblades are far too small for me to work with.

All systems are now functional, cabled up and in place within the Easystar fuselage. I'll be posting some pictures and specs over the weekend and, assuming my 6x4 prop turns up, I will be looking to make the maiden flight tomorrow! :D

Apologies for the low quality picture but you can just about see component placement.

I have placed the GPS and the IR sensors in the tail boom. The TWOG sits in the rear compartment under the motor and the Scherrer LRS RX sits in the middle compartment. The Maxstream modem sits right in the nose and the Video TX will also sit there.

I have made up my own 900MHz dipole (just about visible in picture) which is not only more effective than the previous rubber duck style, it is much lighter. I will also fabricate a 2.4GHz dipole for video once I can get an RPSMA male plug with co-ax.

Overall RTF flight weight looks like it will be around 750g - that is including a 4000mah 2s (not the 2100 in the picture)

More to come shortly....

[vau]

I uploaded a better quality picture (not taken on my phone)

The air-side components include:

TWOG
Vertical & Horizontal IR sensors
Ublox GPS with active Sarantel antenna
USB Connector board
Scherrer LRS RX 3.11c with diversity, two dipoles
ImmersionRC Vid TX (currently rubberduck will be dipole)
Maxstream modem with dipole
Mega 16/15/4 Brushless motor
2 x Hitec HS-81 servos
Xtra 25A ESC
6x4 APC pusher prop
4000mah 2s lipo

The antennae are not in their final locations yet, they will all be vertically orientated

[vau]

An interesting development which occured about 30 mins after opening the parcel containing my APC 6x4 props (which arrived today)


two doctors
half a dozen local anathestics
half a dozen stitches
one tetanus booster
two hours in A&E

That's my kind of party...:D

My front room looks like it's been decorated by Charles Manson... :eek:

[bmw330i]

Ouch, that looks painful.

I'm sure it's something you'll never do twice (this accident). I am very sorry to read this and see that it was a painful lesson.

My rule is if the motor is connected and battery I assume at any time the motor will go full throttle. I never assume otherwise knowing all it takes is a signal to the ESC to go and there are many ways that can happen unexpectedly.

-BMW