How to request data from GPS010?

MFB

Senior Member
The documentation supplied with the GPS010 board covers a PICAXE accepting data that are automatically broadcast by the uBlock GPS receiver once per second. Even though example code demonstrates how to set-up the receiver to broadcast only one type of sentence, this mode of operation can still place a heavy processing load on the PICAXE. Therefore, has anyone develop code for setting up the uBlock mode that allows a single sentence to be sent in response to a PICAXE request? This operating mode could be more comfortably handled by a PICAXE software serial input and leave the hardware serial input and scratchpad buffer free for other tasks.
 

MFB

Senior Member
Thanks hippy, I'll give that a try and post the results. Will certainly download the u-centre application, which looks amazingly useful.
 

MartinM57

Moderator
Yes, interested in the results please :)

You may have to use a MAX232 to connect the uBlox to a PC serial port to use u-center?
 

MFB

Senior Member
Good point. Even though my USB-serial adaptor only outputs the +/-5 volt version of the RS-232 'standars' I will have to be careful to translate this to be compatible with the uBlox's 3.3 volt I/O levels.
 

MartinM57

Moderator
Yes - maybe I meant MAX3232 :) ... or level shifting on the 5v side of the MAX232/your USB-serial.

I wouldn't want to apply 5v to any pin on the uBlox - there's nothing in the datasheet to suggest the device is 5v tolerant and I'm not going to try a test on mine..
 

MFB

Senior Member
I'm now having trouble finding the GPS010 board on the PICAXE web site. Has this recently introduced product been discontinued already?
 

MFB

Senior Member
Thanks, that found it OK but trying to use the site search box still returns no results for 'GPS010'?
 

MFB

Senior Member
Hippy. Rather than constructing hardware to interface a PC (don't have the parts handy), I have been trying to modify the 'Example 1' code provided -in the Rev Ed documentation- to periodically send $IEGPQ from the PICAXE once a minute and look for a response from the GPS010. No problem turning off all sentences, as you suggested, but then receive no response to the period request. Any suggestions would be most welcome.


P.S. Regarding the lack of search results, I was trying to use the box at the top rhs of the www.picaxe.com site.
 

hippy

Technical Support
Staff member
Not really sure why it's not working, though was never sure it would. Check the command is correct and has the correct checksum. Perhaps post the modified code you are using.

You can often use a 74HCxx gate as an inverter using the same current limiting resistor trick as the PICAXE uses to interface to PC serial if you don't have a suitable MAXxxxx RS232 driver.

I've logged a note that the GPS010 isn't documented on the picaxe.com site.
 

MFB

Senior Member
OK, I'll struggle on with trying to set-up the uBlox to send a single GPGGA sentence on request.

On a more positive note, the c-Centre PC application you recommended was able to accept GPGGA sentences from a 28X2 running the 'Example 1' code. Can't wait to start running c-Centre on a laptop to record car trips and display them using Google Earth.
 

MartinM57

Moderator
I've done that with my UBLOX gps as a trial - jumped through some hoops though!
- the equivalent of sending example1 output to pc into a terminal window (used another technology though :))
- pasted the output into a text editor and arranged into csv format with a "latitude,longitude" first record
- using my Google account, upload the file to Google Drive..
- noting that when it displays the file contents, it spots what it is, and there is a tab to "Map latitude"
- click this and you see your points on a Google map...
- and use File | Download to save the points in .kml format back to the pc

...and then you can open the .kml file in Google Earth afterwards/email the file to other people and they can open it in Google Earth etc.

The results were astounding. The ublox accuracy is +/- 2.5m and the registration of my points to Google Earth was nigh on perfect, and looked to be well within this. I could see my driving line around roundabouts, and to be honest, even tell which side of the roof the ublox antenna was on.

With a relatively cheap ublox (I wonder if they'll ever get really cheap?), a microcontroller, some hoop jumping and the free web Google capabilities, I tracked myself to around 1m on a satellite-based map of the world. That's one hell of an accuracy considering all the variables involved.
 
Last edited:

MFB

Senior Member
That's an impressive project! I'll try and get around to seeing if the C-code applications can do it more seamlessly (it appears to have facilities for linking all the stages together).
 

hippy

Technical Support
Staff member
That $IEGPQ seems to have worked fine for me, alternatively polling GLL and GGA messages every 10 seconds.

I have the 20X2 set to transmit to and receive from the GPS010 to configure it and initiate polling requests, the GPS010 output also goes to a terminal emulator to see its output when polled.

Modified Example 1 to disable all messages with polling commands in the main loop at the end of the code. The PICAXE doesn't handle the data returned when polled in this test ...

Code:
#Picaxe 20X2
#Terminal 9600
#No_Table
#No_Data

initialise:

  sertxd( "Initialising", cr, lf )

; Switch to 4800 baud
  serout C.0, T9600 ,( $B5, $62, $06, $00, $14, $00, $01, $00, $00, $00, $D0, $08, $00, $00, $C0, $12, $00, $00, $07, $00, $03, $00, $00, $00, $00, $00, $CF, $E4 ) 
  sertxd("Baud rate changed to 4800",13,10)

; Disable GPGGA
  serout C.0, T4800, ( $B5, $62, $06, $01, $08, $00, $F0, $00, $00, $00, $00, $00, $00, $01, $00, $24 )
  serin [200,initialise], B.6, T4800, ( $B5, $62, $05, $01, $02, $00, $06, $01, $0F, $38 )
  sertxd( "GPGGA disabled", cr, lf )

; Disable GPGLL
  serout C.0, T4800, ( $B5, $62, $06, $01, $08, $00, $F0, $01, $00, $00, $00, $00, $00, $01, $01, $2B )
  serin [200,initialise], B.6, T4800, ( $B5, $62, $05, $01, $02, $00, $06, $01, $0F, $38 )
  sertxd( "GPGLL disabled", cr, lf )

; Disable GPGSA
  serout C.0, T4800, ( $B5, $62, $06, $01, $08, $00, $F0, $02, $00, $00, $00, $00, $00, $01, $02, $32 )
  serin [200,initialise], B.6, T4800, ( $B5, $62, $05, $01, $02, $00, $06, $01, $0F, $38 )
  sertxd( "GPGSA disabled", cr, lf )

; Disable GPGSV
  serout C.0, T4800, ( $B5, $62, $06, $01, $08, $00, $F0, $03, $00, $00, $00, $00, $00, $01, $03, $39 )
  serin [200,initialise], B.6, T4800, ( $B5, $62, $05, $01, $02, $00, $06, $01, $0F, $38 )
  sertxd( "GPGSV disabled", cr, lf )

; Disable GPRMC
  serout C.0, T4800, ( $B5, $62, $06, $01, $08, $00, $F0, $04, $00, $00, $00, $00, $00, $01, $04, $40 )
  serin [200,initialise], B.6, T4800, ( $B5, $62, $05, $01, $02, $00, $06, $01, $0F, $38 )
  sertxd( "GPRMC disabled", cr, lf )

; Disable GPVTG
  serout C.0, T4800, ( $B5, $62, $06, $01, $08, $00, $F0, $05, $00, $00, $00, $00, $00, $01, $05, $47 )
  serin [200,initialise], B.6, T4800, ( $B5, $62, $05, $01, $02, $00, $06, $01, $0F, $38 )
  sertxd( "GPVTG disabled", cr, lf )

  sertxd( cr, lf, "Polling", cr, lf)

mainloop:

  Pause 10000
  SerTxd( "Polled GLL", cr, lf )
  SerOut C.0, T4800, ( "$IEGPQ,GLL*21", cr, lf )

  Pause 10000
  SerTxd( "Polled GGA", cr, lf )
  SerOut C.0, T4800, ( "$IEGPQ,GGA*27", cr, lf )

  goto mainloop
This version polls GLL every 10 seconds and processes the results on the PICAXE and reports them via SERTXD. Effectively Example 1 but using polled data ...

Code:
#Picaxe 20X2
#Terminal 9600
#No_Table
#No_Data

initialise:

  sertxd( "Initialising", cr, lf )

; Switch to 4800 baud
  serout C.0, T9600 ,( $B5, $62, $06, $00, $14, $00, $01, $00, $00, $00, $D0, $08, $00, $00, $C0, $12, $00, $00, $07, $00, $03, $00, $00, $00, $00, $00, $CF, $E4 ) 
  sertxd("Baud rate changed to 4800",13,10)

; Disable GPGGA
  serout C.0, T4800, ( $B5, $62, $06, $01, $08, $00, $F0, $00, $00, $00, $00, $00, $00, $01, $00, $24 )
  serin [200,initialise], B.6, T4800, ( $B5, $62, $05, $01, $02, $00, $06, $01, $0F, $38 )
  sertxd( "GPGGA disabled", cr, lf )

; Disable GPGLL
  serout C.0, T4800, ( $B5, $62, $06, $01, $08, $00, $F0, $01, $00, $00, $00, $00, $00, $01, $01, $2B )
  serin [200,initialise], B.6, T4800, ( $B5, $62, $05, $01, $02, $00, $06, $01, $0F, $38 )
  sertxd( "GPGLL disabled", cr, lf )

; Disable GPGSA
  serout C.0, T4800, ( $B5, $62, $06, $01, $08, $00, $F0, $02, $00, $00, $00, $00, $00, $01, $02, $32 )
  serin [200,initialise], B.6, T4800, ( $B5, $62, $05, $01, $02, $00, $06, $01, $0F, $38 )
  sertxd( "GPGSA disabled", cr, lf )

; Disable GPGSV
  serout C.0, T4800, ( $B5, $62, $06, $01, $08, $00, $F0, $03, $00, $00, $00, $00, $00, $01, $03, $39 )
  serin [200,initialise], B.6, T4800, ( $B5, $62, $05, $01, $02, $00, $06, $01, $0F, $38 )
  sertxd( "GPGSV disabled", cr, lf )

; Disable GPRMC
  serout C.0, T4800, ( $B5, $62, $06, $01, $08, $00, $F0, $04, $00, $00, $00, $00, $00, $01, $04, $40 )
  serin [200,initialise], B.6, T4800, ( $B5, $62, $05, $01, $02, $00, $06, $01, $0F, $38 )
  sertxd( "GPRMC disabled", cr, lf )

; Disable GPVTG
  serout C.0, T4800, ( $B5, $62, $06, $01, $08, $00, $F0, $05, $00, $00, $00, $00, $00, $01, $05, $47 )
  serin [200,initialise], B.6, T4800, ( $B5, $62, $05, $01, $02, $00, $06, $01, $0F, $38 )
  sertxd( "GPVTG disabled", cr, lf )

  sertxd( cr, lf, "Polling", cr, lf)

mainloop:

  Pause 10000
  SerTxd( "Polling GLL", cr, lf )
  SerOut C.0, T4800, ( "$IEGPQ,GLL*21", cr, lf )

  serin [2000,mainloop], B.6, T4800, ( "$GPGLL," ), #w1,#w2,w3, #w4,#w5,w6, w7,w8,w9,w10,w11,w12,w13, #w14,w15

  if w15 <> "A" then
    sertxd( "no lock", cr, lf )
    goto mainloop
  end if

  ; Print 4916 45114 N
  sertxd( #w1, " ", #w2, " ", w3, 9 )

  ; Print 12311 12437 W
  sertxd( #w4, " ", #w5, " ", w6, 9 )

  ; Print 22:54:44
  sertxd( w8, w9, ":", w10, w11, ":", w12, w13, cr, lf )

  goto mainloop
 

hippy

Technical Support
Staff member
Polling requests with checksums for the messages we disabled. Not all tested ...

$IEGPQ,GGA*27
$IEGPQ,GLL*21
$IEGPQ,GSA*33
$IEGPQ,GSV*24
$IEGPQ,RMC*3A
$IEGPQ,VTG*23
 

MFB

Senior Member
What a Star!!! This should really help make the uBlox more PICAXE friendly. I suspect that few applications require new position data every second and this polled mode would drastically reduce the processing load on the PICAXE, thus avoiding the need to dedicate the hardware serial input and scratchpad buffer to dealing with GPS data.

Many thanks.
 

hippy

Technical Support
Staff member
$IEGPQ OR $EIGPQ ? (uBlox max6 protocol pdf seems to suggest the latter)?
Well spotted!

The PDF shows "$xxGPQ,sid*cs<CR><LF>" and it seems it doesn't actually matter what one puts as the first two letters, only that the checksum matches with the letters chosen ...

$IEGPQ,GLL*21
$EIGPQ,GLL*21
$ZZGPQ,GLL*2D

That's a bit of luck and I hadn't made the mistake of it seeming to work but had it actually relying on what had previously been sent in an earlier test.

That it can be any two letters I guess is because a device maybe should always output NMEA packets prefixed with its own two letter identifier but the GPS010 doesn't care who is sending to it.

It was a typo and I had meant to use the PDF's suggested $EIGPQ. I simply copied what I'd written in post #2 into the Programming Editor because I couldn't be bothered looking it up in the PDF!
 

hippy

Technical Support
Staff member
I woke up this morning with a realisation that ( apart from trying to figure out how to control and use the GPS010 from its 200 page manual ) the main problem for most applications is having to deal with $GPxxx messages which don't have fixed format, fixed data and has data that is not always immediately usable with a SERIN command.

The obvious solution to this would seem to be to add a PICAXE 20X2 front end that sits between the GPS010 and application PICAXE. That can poll for data from the GPS010 and then send the latest data accumulated to the application PICAXE when requested. That data can be in a format SERIN can use allowing the GPS010+20X2 to be used with any PICAXE or anything else for that matter.

The front end can format decimal degrees and the like to be 5 digit fixed size so #wordvar can be used to receive it and can split time into separate year, month, day, hours, minutes and seconds components for #bytevar. That can be provided for by a "PAXE" message which would be compatible with the NMEA specification.

The other advantage is that a PICAXE application could be used with any other GPS receiver if the 20X2 were modified for that GPS to produce the same "PAXE" message. The disadvantage is of course an extra 20X2 and associated cost but that is low compared to the other costs and effort of coding for raw $GPxxx messages in the application.

The front end can be coded to pass through raw $GPxxx messages so "PAXE" doesn't have to include all information possible but it makes sense to include everything a real application would likely use.

Specifying a standard "PAXE" message would be the first step, so the question is; what information should such a "PAXE" message contain - longitude, latitude, plus time and perhaps ground velocity and bearing. Anything else ?
 

MFB

Senior Member
I think a thread along the lines of "a GPS proceesing engine" was started some time back but fizzled out from lack of interest. Parallax had a GPS board with dedicated processor for use with their Basic Stamp that seemed quite easy to use, with selected data on request etc.

As my current interest is avionics for small latex balloons, I think that the PAXE message should also include altitude information but what would be really nice would be to be able to edit the 20X2 programme to output only selected data.
 

MFB

Senior Member
I woke up this morning thinking that hippy's proposed GPS front end would make a great Rev Ed product, if it was sold as a pre-programmed PIC. There are complete 'trackers' available, with dedicated micros for parsing GPS data for re-transmission over a UHF link, but they do not readily lend themselves to systems integration.
 

hippy

Technical Support
Staff member
No need for a dedicated PIC product when the code required can run on a PICAXE-20X2. It also allows that code to be used as as an example project to let others see how it is done. It is mainly polling $GP messages and then re-assembling the data for output.

I have the main code working and generating PAXE messages with the option to include and exclude specific parts -

Position ( latitude and longitude )
Altitude
Date
Time
Heading
Magnetic Heading
Speed (KPH)
Speed (Knots)

With the 'PAXE transmitter' configured to just send position, a PICAXE receiver can grab position and report that with something as simple as ...

Code:
Do
  High B.1
  SerIn C.0, N2400, ("$PAXE,P," ), b10,#w11,#w12,#w13, b20,#w21,#w22,#w23
  Low B.1
  SerTxd( "Latitude = ", b10, " ", #w11, "." )
  BinToAscii w12, b5,b4,b3,b2,b1 : SerTxd( b4,b3,b2,b1 )
  BinToAscii w13, b5,b4,b3,b2,b1 : SerTxd( b4,b3,b2,b1 )
  SerTxd( CR, LF )
  SerTxd( "Longitude = ", b20, " ", #w21, "." )
  BinToAscii w22, b5,b4,b3,b2,b1 : SerTxd( b4,b3,b2,b1 )
  BinToAscii w23, b5,b4,b3,b2,b1 : SerTxd( b4,b3,b2,b1 )
  SerTxd( CR, LF )
Loop
That should show something in degree minute format ( dddmm.mmmmmmmm ) similar to -

Latitude = N 5149.34521200
Longitude = W 236.27420100

The current code works standalone but needs some tweaking and testing to check it can be controlled as simply as above.
 

MFB

Senior Member
It would be great to see fully functional and documented code posted in under the Circuit Creator or Project section, as hippy's idea of a 20X2 front-end would be of great help to those starting on a GPS based project.
 

hippy

Technical Support
Staff member
Sorry Armp; got distracted and haven't done much with it. Wanted to get it controlled by a remote PICAXE but haven't done that yet. I'll tidy it up and post what I have. Probably tomorrow.
 

Armp

Senior Member
I'm just getting started on my project. My GPS uses the NEO 6M module that seems to be pretty much the same as the GPS010. But I'm still plowing thru (ploughing through) the 200+ pages of the User Guide. I don't yet see how the GPS010 example code was derived?

Happy to work with you on code and docs.
 

hippy

Technical Support
Staff member
I'm still plowing thru (ploughing through) the 200+ pages of the User Guide. I don't yet see how the GPS010 example code was derived?
Which part(s) of the example code ?

For the disabling messages, for example disabling GPGGA ...

$B5, $62, $06, $01, $08, $00, $F0, $00, $00, $00, $00, $00, $00, $01, $00, $24

That's a UBX Protocol messages which splits into ...

$B5 $62 | $06 $01 | $08 $00 | $F0 $00 $00 $00 $00 $00 | $00 $01 | $00 $24

$B5 $62 is the UBX protocol header
$06 $01 is the ID for a CFG-MSG command
$08 $00 is the message class and ID for GGA
$F0 $00 $00 $00 $00 $00 sets which interfaces carry / don't carry the message
$00 $01 is checksum A
$00 $24 is checksum B

If you search for the $06 $01 ( actually search for 0x06 0x01 ) you should find the entry which identifies it as MSG-CFG and describes that particular message.

In terms of approaching it from the other direction; choosing messages to use to achieve something: It's a question of identifying which message does as required, then determining what the data payload would be.

That means either understanding the whole thing, or - and there's no shame in it - 'cheating' and seeing what others have done themselves, taking their examples ( as above ) seeing how the message is formed and modifying it as required. Through that one would eventually understand the whole thing as the epiphanies arrive, or at least enough to do what is required.

Understanding each little bit ( even if only a little bit ) makes the rest more understandable. It is a bit like picking up a maths book and trying to understand what it all means.
 

Armp

Senior Member
In terms of approaching it from the other direction; choosing messages to use to achieve something: It's a question of identifying which message does as required, then determining what the data payload would be.

That means either understanding the whole thing, or - and there's no shame in it - 'cheating' and seeing what others have done themselves, taking their examples ( as above ) seeing how the message is formed and modifying it as required. Through that one would eventually understand the whole thing as the epiphanies arrive, or at least enough to do what is required.
Exactly! In this case I'm resort to 'cheating' by using your code, with help from the u-Center software. :)
 

hippy

Technical Support
Staff member
Code 'as is' for a PAXE Message Engine.

With TX pin set to A.0 it runs in a debug mode where it returns all the data it can via the Download Serial Out pin at 9600 baud along with all the normal debugging / diagnostic messages. Only that starting with $PAXE would normally go to the PICAXE requesting information.

The non-debug mode hasn't been tested at all.

There's a rough manual and mostly right apart from the $PAXE message header. You'll probably get a good idea of how it works at power up and as messages become available as a satellite lock is found. Wanting all information, you should initially see ...

$PAXE,paDThmsk, ... with only date and time following
$PAXE,PADThmsk, ... with position and altitude
$PAXE,PADTHMSK, ... if it thinks it's moving!

Basically the letters say what data has been requested, lower case means requested but not available and not included in the payload, upper case means it's in the payload. So if you actually only requested date (D) and time (T) you'd get one of the following

$PAXE,dt*cs - No data
$PAXE,dT,20,15,32*cs - Time only
$PAXE,Dt,2013,05,23*cs - Date only
$PAXE,DT,2013,05,23,20,15,32*cs - Date and time
 

Attachments

Armp

Senior Member
Which part(s) of the example code ?

For the disabling messages, for example disabling GPGGA ...

$B5, $62, $06, $01, $08, $00, $F0, $00, $00, $00, $00, $00, $00, $01, $00, $24

That's a UBX Protocol messages which splits into ...

$B5 $62 | $06 $01 | $08 $00 | $F0 $00 $00 $00 $00 $00 | $00 $01 | $00 $24

$B5 $62 is the UBX protocol header
$06 $01 is the ID for a CFG-MSG command
$08 $00 is the message class and ID for GGA
$F0 $00 $00 $00 $00 $00 sets which interfaces carry / don't carry the message
$00 $01 is checksum A
$00 $24 is checksum B
OK - here's where I get stuck!
I'm using ublox 6 document GPS.G6-SW-10018-D, "u-blox 6 Receiver Description".

It 'seems' to parse the above msg down as follows:
$B5 $62 is the UBX protocol header
$06 $01 is the ID for a CFG-MSG command (Pg 82)
$08 is the msg length
$00 ????
$F0 $00 is the message class and ID for GGA (pgs 52,115)
$00 $00 $00 $00 $00 $00 sets which interfaces carry / don't carry the message
$01 is checksum A - 1 byte (pg 84)
$00 ???
$24 is checksum B - 1 byte (pg 84)

For the life of me I can't see what I'm doing wrong?
 

hippy

Technical Support
Staff member
One bug; doesn't actually affect the code ...

Symbol xxxxxMxx = %00000010 ' Magnetic Heading
Symbol xxxxxxSx = %00000100 ' Speed (KPH)

Should be ...

Symbol xxxxxMxx = %00000100 ' Magnetic Heading
Symbol xxxxxxSx = %00000010 ' Speed (KPH)
 

hippy

Technical Support
Staff member
For the life of me I can't see what I'm doing wrong?
Seems you're right; my description was wrong. Should have paid closer attention to the datasheet. The length is however a two byte value, so ...

$B5 $62 | $06 $01 | $08 $00 | $F0 $00 | $00 $00 $00 $00 $00 $01 | $00 | $24

$B5 $62 is the UBX protocol header
$06 $01 is the ID for a CFG-MSG command
$08 $00 Number of data bytes (8)
$F0 $00 is the message class and ID for GGA
$00 $00 $00 $00 $00 $01 sets which interfaces carry / don't carry the message
$00 is checksum A
$24 is checksum B
 

Armp

Senior Member
Thanks!! Now I understand. We'll call that a learning exercise for both of us :)

Now I can go enjoy a nice pint of Ruddles County on a brutally hot day here in NY....
 

hippy

Technical Support
Staff member
Enjoy your Ruddles! Extra information which is useful -

Class ID's are found in "19 NMEA Messages Overview", for example ...

55 | GGA | 0xF0 0x00 | Global positioning system fix data

The six interfaces are defined in "4 Serial Communication Ports Description" ...

0 DDC (I2C compatible)
1 UART 1
2 UART 2
3 USB
4 SPI
5 reserved

CFG-MSG actually sets the report rate, $00=Never, $01=Every one second, $nn=Every N seconds.
 

Armp

Senior Member
Hippy - many thanks for the extra info, and the code. I think I'm almost ready to solo!
I don't know how I missed that LENGTH was a 2 byte field, maybe because its little endian.

Just one more thing for now - why is the disable string "$00 $00 $00 $00 $00 $01" rather than "$00 $00 $00 $00 $00 $00"?

The Ruddles was excellent. Had to chill it in the frig (gasp!) to get it down to 50F, and repeat halfway through when it got up to 58F. I think its time for a solar powered picaxe and peltier temperature controlled pint glass? Or maybe a styrofoam sleeve :cool: .
It's forecast to get into the mid 90s again today - I'll have to repeat the experiment!
 

hippy

Technical Support
Staff member
Just one more thing for now - why is the disable string "$00 $00 $00 $00 $00 $01" rather than "$00 $00 $00 $00 $00 $00"?
Honest answers would be (1) that I don't know or cannot remember, (2) it is what someone else's example code specified, or (3) the original example had a $01 somewhere to enable it on some interface, and moving it into the 'reserved' interface kept the checksums the same which saved the effort of recalculating those.

In a perfect world I would say they should all be $00.
 

Armp

Senior Member
Actual answer appears to be that the u-Center software does not modify the 'reserved' field.

View attachment 14434

If a sentence is OFF by default, the firmware has all zeros
CFG-MSG - 06 01 08 00 0D 06 00 00 00 00 00 00

If ON by default, the firmware has all ones
CFG-MSG - 06 01 08 00 F0 00 01 01 01 01 01 01

However if ON by default, and turned OFF by the user you get a mix
CFG-MSG - 06 01 08 00 F0 00 00 00 00 00 00 01

So this is what you get when you cut'n'paste from the config file....

Thanks to your examples I think I finally understand this beast!
 
Top