Setting up to do more than just change Firmwares

[Irish Steve]

My brain hurts!!!!

I've spent a lot of time over the last few days reading a lot of threads about where things are going, and getting even more confused than I already was in terms of what can or cannot be done. No real surprise there, it's clear that there are some very capable people here that I am sure would be prime candidates for companies like Futaba, and others of that ilk, but I suspect that those same individuals would not be overly interested in fitting into what could well be very odd shaped holes.

OK, now, to the meat. I have some electronics and aviation experience in things like panels, and some PC experience doing interface work to make switches work on large panels in a way that the software can see, and related coding, as well as (a very long time ago) programming very early mini computers in assembler language, as well as fixing them at a hardware level. I've also done a lot of more traditional programming work over a long period of time.

What I'm now looking at it is the electronics side of modelling, and I don't know where that's going to lead me, at the moment, I'm working with helicopters, but fixed wing is going to come before too long, and that's going to have it's challenges in terms of the additional items that will be wanted, and that are not as easy to do right now with the present hardware structures of the radio systems.

So, As some of the hardware doesn't do what I think I'm going to need, some extra work will be needed.

The first project I hope will be easy, an add on card that will take a servo channel pulse and break it down into a set of digital/binary values that can be used for switching things on and off, like lights, strobes, beacons, maybe even landing gear, bomb bay doors, effectively pretty much anything that needs to be On or Off, and the way I see that happening is to have a number of switches that will give stepped values to an existing analog channel, which can then be decoded at the other end, and output to a switch (or relay) control system. A digital conversion of a stick position is probably 12 bit (I think), so if that's shifted several bits to get rid of the jitter, it should be possible to put 8 digital bits multiplexed on to one servo channel, especially if the values can be tuned on the receiver

It may well have already been done, but it if has, I can't find it, and it's not for the absence of searching, I might be using the wrong search terms, but the bottom line is that I've not yet found what I'm looking for. I'm assuming that there's no spare bytes in the present protocol that could be hijacked for this, and that there's no spare pins on the transmitter or receiver that would facilitate a number of digital channels, if there are, that could save a lot of extra work

So, that's the start, and before too long, other micro processor based things will probably happen.

I've several 9X variants here, a smartieparts card, and some HK USB ISP programmers, but I'm well aware that if I'm going down that road, I may have to look at other equipment that will allow me to do debug work, and other testing.

I have reasonable soldering tools, magnifying lenses, third hand, stuff like that, and I have a number of PC's and a couple of laptops that can be used for coding, analysing, or networking for testing of results. I've also got reasonably good digital volt meters and the like.

The area I'd like some guidance from the experts here is the areas of Atmel boards for developing/testing, so that if I am working with (say) an arduino, or other related chips, what hardware tools will I need in order to be able to make sure that what I'm working on is doing what I expect, and what debug tools are needed. My oscilloscope is so old, heavy and the like I doubt it's any good now, it's an ancient 30 Mb dual trace analog unit, and I'm not even sure it still works, it's been a while since it was used. Do I need to think of trying to find a digital scope, or an interface that will capture and display on a PC, and if I do, what do I need to look for. Do I need to think about any other specialist items in this area?

The other side of that coin is the software that's needed in order to put it all together. Is there a "standard" compiler that's being used for things like ER9x, and other versions, which is stable, and can be relied on not to cause strife? There's not a lot of background information in that area at the moment, in the same way that there's not a lot of clear information about what the advantages or extra facilities of the new boards are, partly I suspect because those closest to them know what can be done.

As an example, I've been trying to find out if the pulse stream from the receiver (basic Flysky) or FRsky, can be captured on one pin.

I'm assuming it comes out of the RF stage of the receiver into the decoding section somewhere, but it depends on the complexity of the receiver, while the pulse stream was readily identifyable on a 27 Mhz Micron kit a LONG time ago, it's possible that it never gets out of a modern chip.

I can see this going down roads like FPV, and maybe even Ardupilot.or Arducopter, and ideally, I want to be able to make sure what's going on with these devices.

I have some other ideas, but they are not for the open forum, not yet.

Enough.

Ideas, pointers, suggestions appreciated

Thanks

Steve

[gohsthb]

Arduino has it's own website, but you probably already knew about that. The best part about testing code on an Arduino is the usb serial port, and libraries that make using it really simple. Any debugging that needs to be done, just output a variable or text to the serial port.

Do you need an expensive new digital scope? Depends on what you are doing and think you will need it for. Don't get sucked in by the low prices of some of the PC scopes. Check the specs some of those aren't very fast. (like kHz speeds)

The best tool I have is a Logic from http://www.saleae.com/. It's an 8 channel logic analyzer, and only $150!

For the stock board firmwares gcc is the compiler of choice. WinAVR is available for windows. Or on linux just install avr-gcc.

Some new receivers will output a ppm stream now. Check out Frsky-rc.com. Here is one example

-Gohst

[Irish Steve]

Arduino has it's own website, but you probably already knew about that. The best part about testing code on an Arduino is the usb serial port, and libraries that make using it really simple. Any debugging that needs to be done, just output a variable or text to the serial port.

So I'm guessing that an appropriate program on the PC can then grab whatever's being squirted at the serial port, and display/capture or do whatever with it. Used to do that all the time debugging COBOL on a mini, was the only tool we had to find out where the program was going and what it was doing.

Do you need an expensive new digital scope? Depends on what you are doing and think you will need it for. Don't get sucked in by the low prices of some of the PC scopes. Check the specs some of those aren't very fast. (like kHz speeds)

Fair comment, I'm not sure yet, if I can keep it mainly digital, then no, I won't which will be good.

The best tool I have is a Logic from http://www.saleae.com/. It's an 8 channel logic analyzer, and only $150!

OK, i shall have a look at that.

Compiler should be simple enough then, I can dedicate a Win machine to that, which avoids "contamination". Will also look at the receivers that are coming,

Many thanks

Steve

[Kilrah]

An arduino will easily let you capture a servo signal, and take decisions depending on its value, so you could turn outputs on/off depending on the input. Those outputs could control transistors to switch DC appliances on/off, which sounds like what you need. The alternative 9x firmwares will also easily let you encode several input controls to match that decoding without modification.

What I see as a limitation is the number of control inputs you have on the 9x. We have 7 switches and 3 pots on the radio, so you might need to start getting creative if you want to control 8 auxiliary functions plus the flight-related stuff...

[ReSt]

If a PPM stream is available on any pin of a receiver, than this stream was especially built by the firmware of the receiver.
There exists no ppm stream over the air. Only digital values are transmitted. And the receiver rebuilds the servo pulses from these digital values.

Reinhard

[Irish Steve]

What I see as a limitation is the number of control inputs you have on the 9x. We have 7 switches and 3 pots on the radio, so you might need to start getting creative if you want to control 8 auxiliary functions plus the flight-related stuff...

I have to admit I was hoping there might be some "spare" input pins on the processor, if they are all full, I will sacrifice one of the 3 pots, and set up a switch array that will make the output of the new "pot" the correct binary equivalent of the value needed. Seen a circuit for doing it, it could even be done by having a switch to allow use of either the pot or the switches, and that might even be technically doable in the firmware depending on spare switching options. I'll only start finding that out when I get to grips with the alternates more closely, for now, I've just been reading up on the ATTiny, and the Picaxe, and even the small versions will probably be capable of doing what I'm looking for, as long as we're careful with total current requirements.

I'm surprised that no one has already done this, given the number of digital items that are possible,

It's getting a lot closer than I first thought.

Thanks for the pointers

Steve

[Irish Steve]

If a PPM stream is available on any pin of a receiver, than this stream was especially built by the firmware of the receiver.
There exists no ppm stream over the air. Only digital values are transmitted. And the receiver rebuilds the servo pulses from these digital values.

Reinhard

Ahhh, that's the piece of information I've not been finding, and it explains a lot! OK, not a show stopper for what I'm trying to do at the moment, and hopefully, in future, it will just be a case of getting a digital data string output on a serial pin, which an external processor can do extra work with if needed.

Many thanks

Steve

[MikeB]

If you want more inputs to the Mega64, look at the TelemetrEZ board being developed. This has a number of spare inputs, and these can be passed to the M64 over the serial interface. I think you cn get up to 10 extra inputs, and can select between digital and analog. This is for the stock board, but remember the FrSky telemetry version of the code is very short on flash (program) space.

You might consider using the ersky9x board, more powerful processor, plenty of flash and RAM, and a co-processor that also provides extra inputs.

Mike.

[Irish Steve]

If you want more inputs to the Mega64, look at the TelemetrEZ board being developed. This has a number of spare inputs, and these can be passed to the M64 over the serial interface. I think you cn get up to 10 extra inputs, and can select between digital and analog. This is for the stock board, but remember the FrSky telemetry version of the code is very short on flash (program) space.

You might consider using the ersky9x board, more powerful processor, plenty of flash and RAM, and a co-processor that also provides extra inputs.

Mike.

Now you know why my brain hurts The diversity of what's happening in just the 9X area at the moment is challenging, I don't know how you stay on top of it, but I've done "fun" projects before, and they do provide their own motivation.

TelemetrEZ is indeed a possible, and yes, I've already come to the conclusion that at some stage, the ERsky board will figure in this scenario. The absolute key to this is the open source aspect, a while back, when I was doing behind the scenes work with flight simulators, the factor that decided between which one we went with was the degree of access to the core information, and if a developer can't get access to the areas that matter, it can kill the project.

It's going to take a little while to get up to speed on all of this, and to set up the relevant development and coding environments, I will drop you a PM with some more specifics that might be of interest.

Thanks

Steve

[rperkins]

...The absolute key to this is the open source aspect, ....., the factor that decided between which one we went with was the degree of access to the core information, and if a developer can't get access to the areas that matter, it can kill the project.

concur.

I put together a bench over the winter and talk about equipment choices here.
getting most use out of the hakko iron and rigol scope. Went with separate scope/DA instead of a MSO.
viewtopic.php?f=49&t=502

[Irish Steve]

Like the look of that bench ! My piece of luck is that I don't need to build the bench part, I have it already in my "office", which has a 3 Mtr kitchen worktop along one side, at just the right height for a bench, and things like power, network, and LOTS of light are already near enough in place. Have lots to do on the tools side, which is where posts like your are helpful, I have some very complex long term plans that I have to be a bit careful with for now, but previous full size flying experience, both in real aircraft, and in level D simulators, as well as a background with electronics, computing engineering and programming are all going to be implicated.

For sure it's going to be challeging, which in some respects is probably not a bad thing, we've been hard hit by the recession here, and getting motivated to pick the pieces up and start again has been very difficult to do. and the good thing is that the Arduino hardware is not expensive, which will be a big help.

Thanks for the thoughts

Steve

[Kilrah]

If you plan to buy a scope and intend to work with PPM signals, make sure to get one that has pulse width triggering. It's a real must

[Irish Steve]

Valid point, having said that, I'm kinda hoping that the future is digital, so I won't have to get involved in measuring pulse widths as such.

[Kilrah]

No doubt, what's not sure is how far the future is - IMO, we'll be scoping PPM for many more years, at least while working with gear from different manufacturers.
Don't forget PPM/servo pulses are slowly becoming the only thing that maintains some compatibility between brands.

I certainly do NOT look forward to the day where servos will talk with receivers with a digital protocol that is specific to each manufacturer, locking people into a single brand for everything including servos, like is already the case with 2.4GHz radios and receivers. I already need Futaba, FrSky and Spektrum TX modules to run all my models. Now imagine servos that would only work with one radio brand... and then remember the good'ole days where you could mix PPM radios and receivers from any brand, and with any servo.
Digital between receiver and servos might have a couple of small advantages, but it will sure have more important disadvantages as well.

To me R/C and data have to be separated, at least unless manufacturers agree on a common standard, which seeing the 2.4GHz mess is unlikely to happen anytime soon. Do it like is planned with frsky:
- Radio sends R/C info through one unidirectional digital line to the TX module (i.e. the PPM pin, like for the current PXX implementation)
- Servo outputs on the receiver stay as pulses for now
- Radio talks bidirectional data through the RF module's data port (the RS232 connections on FrSky modules)
- Receivers have the same bidirectional data port to talk to whatever sensors/expanders you want to connect to it (also already there on frsky receivers)

Gives you the freedom to do anything you want on the data side without any restriction on the R/C side, and also without messing with it, critical control info stays separated from non-critical data.

[Irish Steve]

Yes, that sounds about right, and hopefully, PXX will help that significantly. In the flight sim work I did, the important stuff was blasted out at 18Hz in a fixed format packet, and then we put anything else out only when it changed, which meant we could significantly reduce the network traffic, hopefully, at some stage, we can do similar with the radio side, I've got some pretty significant requirements in that area, if you combine FPV and RPV, with more than just a few telemetry fields, you'll get a pretty good idea of where I'm hoping to go long term.

Depending on the application, things like Infra red sensors could also be being used to detect heat differences and feed that back to the base location, but that's a very specific application of RPV, which may or may not happen.

If we could make flight sim PC's autoland with weather and other issues causing disturbance, it can't be too much harder to get models to do it, and the sensor side is pretty much there, and working, it's just a case of getting the algorithms that control the autopilot right. The code won't be that much different, if anything, it might be simpler now with some of the new stuff that's coming on stream now.

Hear what you're saying with servos, you're right, for some time to come, PPM will be the only show in town. Now, if we could piggy back some digital channels on to the 4 bits per channel that we're not using at the moment, ............

[Kilrah]

We already have all that's needed fpr RPV applications, we do have auto landing models, for those that require bidirectional data links we simply use a separate pair of $50 RF data modems to communicate with them from a PC. No need to do that through the R/C link. On the opposite it would probably be a burden, because it wouldn't be so comfortable to set waypoints on a 9x with a 128x64 screen and 6 buttons. We're in the days of clicking on a map on a PC

Some don't even need an R/C transmitter anymore in the first place. Set the mission on the PC before launch with the help of a mission generator (set coverage area -> waypoints and trajectories are calculated automatically), throw the aircraft, go get a coffee and wait until it lands back home, even if data link failed.

[Irish Steve]

Even better, and completely agree about not using the transmitter for the flight planning, way too tedious, much better to have a PC in the loop. Been reading a lot in places like DIY drones, and it's clear that the common factor to much of this is the AT chipset, which makes life much easier.

Will keep going with the road we're on now, and also start building up the bench for the other work that's clearly going to be happening. Has to be a lot more fun than PC based simulation!