Re: Downlink code help

[jdtanner]

Hi Adam,

Feel free to have a look at my GitHub at https://github.com/jdtanner/peaksky/tree/master/peaksky as I've tried to comment my code to be helpful to other people. However, I can't guarantee that there aren't any bugs :) I'm using PWM to drive by NTX2, which seems to work really well, so just be aware of that.

As for Software Serial, I've never had a problem with it provided that I increase the size of the buffer to 128 rather than 64 as standard. 

If you need any help, give me a shout as I'm still very much learning as well.

JT

On Saturday, 9 March 2013 16:33:58 UTC, Adam Dunville wrote:

Hello all, I posted once a long time ago about my HAB project for my degree dissertation and now I'm a little further down the road now in terms of understanding.

After looking through the tutorials and guides available on the UKHAS.org site I have successfully configured my NTX2 434.075 and have had it sending test messages to dl-fldigi (See image below).
I have also managed to test my uBlox max6 breakout board and make it only send out $GPGGA data onto the Arduino IDE serial monitor (See image below).

To broaden my understanding of Arduino code (since I have little to no background knowledge) I have completed most of the learning tasks in Beginning Arduino by Micheal McRoberts as well as looking through the past project pages you have all provided on the wiki.

My problem lies in developing the code that can take my uBlox data and echo it through the NTX2 via the Arduino so that it is ready for a basic prototype style launch, I understand the RTTY function that many use and also most of the setup elements. The section I don't understand is the actual GPS section and what sort of code I need to get the two linked together.

This is my first draft of my "final" code that will be used. I have annotated it quite heavily partly for my understanding and partly for my tutor's, I hope that you can point me in the right direction.

In addition, the uBlox 6 guide suggests it is unwise to use the software serial for final flights, Why is this and what are the alternatives?

Thank you for any help you can offer.

[jdtanner]

Not quite...

Have a read through the code that I sent and see if you can follow it. Hopefully you'll be able to answer your own questions :) If not, give me a shout.

JT

On Saturday, 9 March 2013 17:02:20 UTC, Adam Dunville wrote:

Hi JT,

Thank you for that link, your code is very readable which is great! As far as I can tell, based on yours and others I have stumbled across, I need the sendUBX and getUBX elements. Which are used for constructing the packet? And then I need to develop my loop function which sends the packet through a superbuffer to the RTTY?

I'll have a more detailed read through of what you have shown me and see if I can figure it all out. Thank you!

[John Tanner]

I'm presuming that you are using:

http://ukhas.org.uk/projects:jimbob:bob#tinygps-ubx

If so, then you probably haven't restarted the Arduino IDE :)

On 9 Mar 2013, at 19:30, Adam Dunville <a.dun...@googlemail.com> wrote:

I think I'm starting to get it now which feels pretty damn good after a week of stressing over it.
One thing I have noticed when compiling was that I get an error with tinyGPS, now I notice that the ublox 6 guide suggests that users should have the TinyGPS_UBX version so that it can handle the $$PUBX aspects but everyone I have seen is using the standard TinyGPS as far as I can tell. Which is most suitable?

The error in question is: FINALCODEV5.cpp:94:23: error: ‘class TinyGPS’ has no member named ‘get_datetime’
I have both versions of TinyGPS but I've only put the UBX version in my Arduino library.

--
You received this message because you are subscribed to the Google Groups "UKHAS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ukhas+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[John Tanner]

If you were using that version, then the

Removed:
  get_datetime()

Might explain whey you were getting ‘class TinyGPS’ has no member named ‘get_datetime’  :)

JT

On 9 Mar 2013, at 23:28, Adam Dunville <a.dun...@googlemail.com> wrote:

No I wasn't, I was using the https://github.com/x-f/TinyGPS_UBX version that is at the bottom of the ublox6 guide on ukhas.org.
I'll swap out the library in the morning, try again and post results. Thank for the link.

[Chris Atherton]

Hi Adam,

I was having a similar problem with my code last week, turned out to be a buffer overflow of some sort.  I rewrote my code so that rtty only sends one sprintf within the main loop (I went a bit mad and was sending all sorts).  I can see from your code you have two instances of this.

Chris/Broliv

Sent from my iPhone

On 10 Mar 2013, at 17:13, Adam Dunville <a.dun...@googlemail.com> wrote:

Ok Thanks JT, I've made the changes now.

Change log:

• Adjusted the buffer size in SoftwareSerial.h to 128. as recommended
  
• Swapped out to the other TinyGPS.h (not _UBX anymore).
• Changed some of the names due to compiling issues or so that I can read them more easily.
• Added the success, fail element from the tutorial to GPS to see whats going on there.
  

As of now, what I would class as my "final code" that just handles co-ordinate down-linking compiles fine. 0 errors that it can detect.
However after hooking it up I noticed that my GPS was changing settings fine and receiving the packets in order (All seems great on this end)
RTTY on the other hand seems totally busted. While I am getting some activity from it, its very noisy and there is no data its able to decode at all.

I've included my hardware set up in case I am being a total noob somehow in that aspect.
And my 'final' draft of code is available here. (Haven't applied credit where its due just yet, still trying to get everything working before I start commenting again!)

Thank you for any help you can give.

--
You received this message because you are subscribed to the Google Groups "UKHAS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ukhas+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

<IDE serial monitor.png>

<20130310_165712.jpg>

[John Tanner]

Adam,

As You've found out…sounds like a hardware issue to me; I'm sure the chaps on IRC will be able to offer advice.

JT

On 10 Mar 2013, at 20:58, Adam Dunville <a.dun...@googlemail.com> wrote:

Hey Chris,

My sprintf functions are very similar to a lot of people who have let me have a read through of their code, JT above being a prime example. My first sprintf is the main packet, followed by the checksum.

Having had a further route around in my hardware I found that when I disconnected my power (5v was being shared) that for a few seconds my RTTY was coming through fine.

The guys on IRC (I'm Sierra004 by the way) suggested that some serious decoupling was in order between my 5v and GND lines.

So I'm going to try and eliminate the noise issue on that end before I change my code.

Thank you, and I'm glad at least you got your code working!

[James Coxon]

Hi Adam,

Not sure if you've posted it already but is your code available?

The issue with software serial is that its a bit of a hack (an elegant hack but still a hack), the arduino has a hardware serial port which is much more efficient at do the necessary work to perform the serial communications. The hardware serial will be more resistant to temperature as well as taking up less processing on the atmega then software. However there is good role for software serial, instead of using it for the GPS why not use it for your debugging, you can then turn it all off before flight (or not).

James

On 11 March 2013 23:22, Adam Dunville <a.dun...@googlemail.com> wrote:

I did have a talk on the IRC after I read this, and was told explicitly not to use software serial at all which made my heart sink a little since that would mean scrapping everything I'd been debugging and basically starting again.

I've made this Image of my hardware layout so its a little easier to see although I'm unsure how much that helps.

I am very much lost in the woods at the minute. My code as it stands running software serial I can say with 99% certainty works fine, as soon as I disconnect the GPS from the 5v supply RTTY comes through my Yaesu nicely. You seemed to suggest that there was no issue with using Software serial as it had worked for you and I'd like to stick to it if it's not beyond possibility. However I see a hardware UART setup using the UM232R which doesn't appear to require me to change anything as I'm confused by the act of using the Arduino's own UART. Not sure on the practicality or success of this method though.

Newbies gonna noob

[Costyn van Dongen]

Hi Adam,

I had some trouble with my GPS too (turned out a pin labelled GND on
my Chinaduino wasn't actually connected to ground), and it helped when
I "sniffed" traffic between the Arduino and the GPS. I used a 3.3v
FTDI and I connected the TX of the GPS to the RX of the FTDI while the
GPS TX was also still connected to the RX of the Arduino.

Additionally, I saw in your github code that you posted in an earlier
message that you only send strings when a valid NMEA string has been
received. Most people just have the code sending rtty strings
regardless....

Did you try Upu's rtty test code? It's on the wiki I believe.

Here's my code in case you want to poke around:
https://github.com/costyn/habanero/blob/master/habanero.pde

Cheers

Costyn.

[Adrian Hicks]

I struggled for ages with what you are trying to achieve, the way i eventually cracked it was to just go back to serial and build things up step by step, until everything was working. Changing a couple of things in lots of lines of code can mean there are tiny errors that don't get spotted.

It was good advice that was given to me to keep the loop and setup and short and sweet as possible. i.e keep your gps stuff on its own. otherwise you've just got loads of blurb in what is effectively a fairly simple loop.

Good luck

On 12 March 2013 12:06, Adam Dunville <a.dun...@googlemail.com> wrote:

Hi Costyn,

I've managed to get all of the test code examples on the wiki working its just trying to combine them together at the minute that's causing the headache. I've had some great help from JT, DaveAkerman and loads of the other guys on IRC (Who suggested I replace my software serial prompts with Serial. prompts so SofwareSerial.println -> Serial.println. And connect my GPS to pins 0 and 1, But I can't seem to get that to do anything at all, it just plays a tone through the radio the whole time.

I've uploaded a video so everyone can see and hear just what its doing.

This is my code for trying to get anything working with Softwareserial
Here is my Hardware serial attempt but that doesn't work either unless I'm just connecting it up wrong.

Thanks

[David Morris]

The most obvious issue is that (in the hardware serial case) you are telling the GPS to communicate at 4800 baud and then talking to it at 9600 baud.

I would also echo the advice to factor as much as possible out of the main loop and into separate functions; this will make it easier for you to understand and debug.

I would also suggest that you consider learning a little more about git/github; with proper version control, it will be easier for you to see what you have changed to find out what could have broken it, and every previous working version is available to look at. If this is for your dissertation, you can also probably talk about version control wrt process, traceability, etc., which may make your supervisor happy.

HTH,

David

[John Graham-Cumming]

On Mon, Mar 11, 2013 at 11:22 PM, Adam Dunville <a.dun...@googlemail.com> wrote:

My code as it stands running software serial I can say with 99% certainty works fine, as soon as I disconnect the GPS from the 5v supply RTTY comes through my Yaesu nicely. You seemed to suggest that there was no issue with using Software serial as it had worked for you and I'd like to stick to it if it's not beyond possibility

Adam,

On my flight (GAGA-1) I used a Lassen IQ talking to an Arduino using SoftwareSerial. I was experiencing a problem with garbled RTTY output and it came down to the fact that when the Lassen IQ was sending data interrupts were occurring which was messing up the timing on the RTTY output. By simply disabling interrupts during the RTTY transmit I was able to get it to work.

More details than you want to know: http://blog.jgc.org/2011/04/gaga-1-integration-testing.html, https://github.com/jgrahamc/gaga/commit/652c1c8ff3dda31aeb2fda0c89d80f55bab22ff8

John.

[MikeB]

Hi

Just a general comment for those new to the world of embedded programming. It might be better to start by using the PICAXE microcomputer that uses a Basic interpretor, rather than jumping in at the deep end with the Arduino and it's C++ based compiler (now that's the kind of comment that can kick off an ideological war).

MikeB 

On Thursday, March 14, 2013 12:35:20 AM UTC, Adam Dunville wrote:

Hi everyone thank you for the replies!

With thanks to detailed help from Mark of the STRATODEAN project I eventually got everything working (He basically read through my code and offered up a load of advice)

Essentially I was Serial.print-ing the shutdown commands for the gps packets instead of Softwareserial.print-ing and therefore my GPS was trying to send every type of data at once, jamming my transmitter.

I tested it out and it works perfectly now after making those changes.

So thanks to Mark, Hix, JT, Dave A and everyone else on here and IRC for helping me out!
I'll update my progress soon when I have some decent updates!

[Costyn van Dongen]

I started with a Picaxe but found its BASIC convoluted and annoying to
work with. Was so much happier when moving to C with Arduino which is
much more like other programming languages I was already familiar
with.

If you're going to stick with BASIC, sure, but if you think you might
want to move on to C later, I'm not sure BASIC first would be the
best.

Cheers

Costyn

[Ed Moore]

No time for a reasoned response, in such cases I would usually not say anything, but in this case I can just quote Dijksra:

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

[David Akerman]

The problem isn't C.  The problem (and this isn't aimed at anyone - just a general comment) is that there's a tendency for new HABbers to chuck together a few examples from the wiki and expect a fully working program to emerge.  Of course it never does, often leaving the poor said newbie with a pile of code and no real understanding of how it works.

Programming is all about breaking a problem down into pieces, developing a solution to each little problem, and then tying those solutions together in a logical manner; not pouring a tin of alphabetti spaghetti on a plate and expecting it to say "To be or not to be ...".

C isn't the problem and BASIC most certainly wouldn't be the solution even if it were.

Dave

[Ed Moore]

Indeed, to be less silly than my last email, the problem is that making a GPS receiver and parser work somewhat asynchronously with a 50-baud modulator is a tricky architectural problem, and mostly agnostic of the language choice. Using a language that doesn't encourage you to think about structure doesn't really help.

I've said before that the existing wiki code examples (despite strenuous bold/italic disclaimers) can do more harm than good in that people think it will let them copy and paste and stay a level of abstraction above nitty-gritty software architecture. When it doesn't work you can go to IRC and say 'it doesn't work' in much the same way you might complain about a faulty printer driver on your PC. And then their temptation can be to react in much the same way as I would if someone said 'well just write a new printer driver' (i.e. horror). 

There needs to be an upfront acceptance that building a tracker involves getting your hands dirty at all levels. Or we could go the way of something like Ardupilot, and provide hardware and firmware which come with the expectation that you can just change a couple of parameters like 'payload name' and re-flash and be on your way.

As it stands, we seem to be in something of a no-man's land where there is a bit of an expectations mismatch between us and newcomers. This is probably as much our fault as anyone else's.

Again, aimed at no one in particular, I base this generally from the trends in the last six or seven years of discussion on #highaltitude.

[John Graham-Cumming]

On Thu, Mar 14, 2013 at 11:15 AM, Ed Moore <eddy...@gmail.com> wrote:

I've said before that the existing wiki code examples (despite strenuous bold/italic disclaimers) can do more harm than good in that people think it will let them copy and paste and stay a level of abstraction above nitty-gritty software architecture.

I'm a strong believer in rewriting code like that. When I did my flight I looked at various examples and rewrote everything. Was useful to see how stuff was done (to get the principles) but I wanted to understand the code.

We should encourage people to write their own code and not provide a complete solution IMHO.

And this doesn't just apply to code. The entire thing is worth thinking about. You can learn a lot from seeing what people have done (I know I did), but then come up with your own solutions. 

John.

[Oliver de Peyer]

Personally I can always understand what PICAXE BASIC says whereas I
have never got anywhere with C. Did I put all the { }s in the right
place? Am I missing a ; ??
Wearily, although I personally may be too far gone, I think people
should still try to learn C because it basically underpins Unix and
Linux, and therefore Macs as well, and all of these have the GCC
compiler built in. Even if you want to program in something else
(FORTRAN say) it is basically made up of a bunch of C libraries. So
why not program in C and cut out the potential unreliability of the
middlemen? It compiles crisply, which is why it came to dominate in
the first place.

I personally like breaking things down into pieces by having very
small C applications, passing things back to the BASH shell of Linux,
and then using BASH basically as a simple programming language in
turn. This is no help of course in ArduinoLand but would work for
people flying Raspberry PIs or (in my case) a EuroTech Titan PC104
board.

PICAXE BASIC is compiled too by the way - the only difference between
a PICAXE and any other PIC microcontroller is a bit of proprietary
code that starts up the chip with a serial port on some of the pins to
talk to the PICAXE application for PC, MAC, Linux etc. - so you don't
need a PIC programmer gadget.

Please don't all have a go at me, I have already admitted my shameful
C illiteracy and made contrition ;-)

Ol

On Thu, Mar 14, 2013 at 10:58 AM, David Akerman <da...@sccs.co.uk> wrote:

[Matthew Brejza]

Ive been looking for some comparisions between arduino and PICAXE and came along these if people wanted to have a quick read through

http://www.picaxeforum.co.uk/showthread.php?23374-Arduino-experience
http://www.picaxeforum.co.uk/showthread.php?10903-Arduino-gt-PICAXE
http://www.picaxeforum.co.uk/showthread.php?21079-PICAXE-amp-Arduino-(code-size-comparisons-just-for-fun)

[Ed Moore]

I know you asked people not to have a go at you, so I won't, but instead I will just comment on what you wrote, just in-case someone reads it, because mostly everything you just said is incorrect and I don't want newcomers to be even more confused. Except I agree with your general conclusion (learn C), if that helps.

On Thu, Mar 14, 2013 at 11:33 AM, Oliver de Peyer <go.ver...@googlemail.com> wrote:

Personally I can always understand what PICAXE BASIC says whereas I
have never got anywhere with C. Did I put all the { }s in the right
place? Am I missing a ; ??
Wearily, although I personally may be too far gone, I think people
should still try to learn C because it basically underpins Unix and
Linux, and therefore Macs as well, and all of these have the GCC
compiler built in.

Minor point but they don't. At least on the most popular linux distribution, Ubuntu, you have to download it yourself, and OSX now uses LLVM and Clang, instead of GCC, by default, which you have to install as a separate thing with XCode (or you can get it some other way).

 

Even if you want to program in something else
(FORTRAN say) it is basically made up of a bunch of C libraries.

No, it's usually the other way round. Fortran is almost two decades older than C and usually Fortran is given a C wrapper when used today, especially in numerical code, for example the omnipresent BLAS library that has CBLAS as a wrapper. That's assuming it's not just all done in Fortran, eg you're a thermodynamics professor who doesn't trust all this new-fangled C stuff.

 

So
why not program in C and cut out the potential unreliability of the
middlemen? It compiles crisply, which is why it came to dominate in
the first place.

I think this is a debatable reason for its domination but such a debate would be well off-topic.

 

I personally like breaking things down into pieces by having very
small C applications, passing things back to the BASH shell of Linux,
and then using BASH basically as a simple programming language in
turn. This is no help of course in ArduinoLand but would work for
people flying Raspberry PIs or (in my case) a EuroTech Titan PC104
board.

It's just so much damn weight of software (and batteries!) to fly in a hab. To use the requisite car analogy, it's like being given the task of transporting an acorn around the block and so running off to buy a flat-bed truck. I don't see why you would do it like that, unless you need all the extra flexibility and power afforded by a pi or a typical pc104 card, which you absolutely do not unless you're doing something more involved than a normal flight tracker. But there's no need to re-do the debate you had with the list about this before.

 

PICAXE BASIC is compiled too by the way

Not really no. The way they do it, as I understood it, and a quick google doesn't give me cause to disbelieve, is that the PICAXE system flashes a basic interpreter onto the chip, which then runs the (uncompiled) basic code that you write. This is partly why their performance is so pedestrian.

 

- the only difference between
a PICAXE and any other PIC microcontroller is a bit of proprietary
code that starts up the chip with a serial port on some of the pins to
talk to the PICAXE application for PC, MAC, Linux etc. - so you don't
need a PIC programmer gadget.

 

I think you're describing a bootloader, which is not really an accurate description of the PICAXE firmware, as described above. You've infact just described how the Arduino works.

Please don't all have a go at me,

I didn't :)

[Oliver de Peyer]

You're right... I had been using Fedora (which does have GCC) and my
Mac had Xcode.
Linux without GCC?? That seems incredible, surely Gnu GCC underpinned
the entire open source effort.
And as far as I can see if you went looking for a free Fortran for
Linux you'd probably end up right back at... GCC again:
http://gcc.gnu.org/fortran/

I agree that the Pi or anything above that seems like overkill. There
were specific reasons that I used a PC104, namely that I was hanging
out with CubeSat people at the time and thought it might turn into a
CubeSat project (which at the time was all built on PC104, but now I
see there are ArduinoSats too?)

How about BeagleBone boards then?
http://beagleboard.org/bone

It has Linux and it is quite small, but unlike Pis it doesn't waste
any space or power on display ports etc, although I notice wearily
that it does have a 3D graphics accelerator. All I really want is
basic, pared-down Linux, several serial ports (The Beagle has 5) and
lots and lots of pins.
I leave it to you all to argue over the difference between this and
the most complicated Arduinos, since I have no direct experience of
either. I have no idea if Angstrom has GCC, perhaps somebody who has
used it could let me know (I couldn't glean this from their FAQ)

Looking at the PICAXE FAQs quickly, it says:
http://www.picaxe.com/Software/Drivers/PICAXE-Compilers/
“The compilers, which are available for Windows, Mac and Linux, are
console applications that both compile and download your BASIC text
file.”
- whether they are just using the word “compile” loosely, I just know.
For it also says:
http://www.picaxe.com/FAQs/Programming-Techniques/
“The BASIC commands are converted to a tokenised form when downloaded
so are not stored within the PICAXE memory as either source code nor
as assembler code.”
So what does that mean? I have no idea.

And from the FAQs:
http://www.picaxe.com/FAQs/Fault-Finding/
“The PICAXE microcontroller is not a blank PICmicro! It is a
microcontroller that has been pre-programmed with a 'bootstrap'
program that enables the download via the direct cable link (the
bootstrap program tells the microcontroller how to interpret the
direct cable programming commands).”

I never said there was a difference in how the Arduino and PICAXE got
programmed, just that you didn't need a programmer gadget for PICAXEs
either. There is nothing wrong with programmer gadgets come to that,
which would open up a world of other microcontrollers.

All this doesn't really matter, or maybe it does a bit, because
PICAXEs seem quite cheap and handy, so if there is strong consensus
that they are rubbish then maybe they should be avoided. To be fair, I
think they started out as a simple schools kit and have basically gone
way beyond that as a simple and easy to use microcontroller. I still
have an inkling that if you have thousands of lines of code on an
Arduino, it might be time to think about taking a step up to something
like a BeagleBone with an operating system, but that might just be my
pecadillo. If I ever get round to (re)building something to fly, I'll
let you know...

BTW I have got a 3D printer now, so I can at least make hardware, if
not get around to the electronics. If this would be useful to anybody,
let's talk.

Ol

[David Akerman]

Yes even a Pi is overkill for most trackers, though it does make SSDV a lot easier and potentially with better results.  For a basic tracker I wouldn't think of flying it - it would just add weight and possible unreliability.  If I wanted lots of serial ports I'd be looking at an Arduino Mega or perhaps add i2c UARTs to a more basic Arduino.  Basically whatever can do the job and is small, light and reliable.  PC104 is going to fail on 2 of those.

Tokenised code isn't compiled code.  All they've done is swap (e.g.) "FOR" in ASCII with some number meaning "FOR", and possibly/probably convert into reverse-polish to make it nice and easy for the interpreter on the chip.  It's a decades old technique and compilation it is not.  All it does is speed up and simplify the execution of the code, a bit.  Real compiled code will be much, much faster.

Dave

[MikeB]

Well, a pretty predictable response. Those already competent at programming in C just can't understand why anyone would want to use Basic. However, I think we also need to consider the associated development environment. The Basic Stamp and PICAXE IDE packages seem to have been specifically design for the occasional/reluctant programmer and it is amazing how many zoologist, oceanographers etc have been able to develop unique instrumentation using these tools. Maybe we should just make newcomers to programming aware of the options and they can decide whether to take a look at the PICAXE web site.

MikeB