I’m very grateful for your help. Hopefully, this can be resolved with a bit of code tweaking. I was relieved to discover I don’t seem to have killed the thing and it is working, albeit with an American accent. 
I’ve broken the shackles of domestic bondage for a couple of hours in exchange for cooking Sunday Dinner but this is a head scratcher.
I grabbed the nearest machine, in this case a clean Windows 7, put the right versions on as per my recipe, and whilst it says it’s doing things, it doesn’t transmit. PANIC!
So after a clean out of the Arduino cruft on my iMac, put IDE 1.8.9 & LMIC 2.2.2 on and hey presto, it just works.
Now to find a random Linux machine to try this on and then see if I can pick through the Windows issue.
Thank you, that is weird. I thought I had found something in the config.h file as the radio is not defined, specifically line #50 is commented out but removing the // makes no difference.
A very common cause of this is a new event code in MCCI LMiC which indicates part of the join cycle. Unless someone’s Arduino sketch has a message for that event code, it ends up as “uknown”
If MCCI LMiC is being used I believe they have examples on how to do things for different regions (they not only do non-radiating instrumented testing on various bands distinct from where they are sitting, but their own on-air efforts also span a number of countries with different bandplans). The code, er mis-management philosophy of the Arduino IDE does make it challenging, but it’s not a new or novel challenge but essentially something faced by anyone who uses it.
From what I have discovered the “Unknown event” message isn’t a problem. It is written in the code at the end of a list of “Case” options which cover specific errors. If none of these errors occur then it prints the message but it also means the message is printed when no error was found. That’s my understanding so far anyway.
The case statement attempts to interpret codes representing events, only some of those events are “errors” of any sort.
At least EV_RXSTART and EV_JOIN_TXCOMPLETE are recent additions to the MCCI repo; EV_TXCANCELED may(?) also be but is a little older than the others.
1 Like
A rather long winded testing of multiple combinations, but progress! The not-published release of an alternative implementation (or wrapper, as most are getting the original IBM code suitable for the Arduino) works on both Windows & macOS using the latest Arduino IDE:
Download as a zip, unzip and put it in your libraries folder and remove the other library.
I would strongly recommend using the TTN-ABP example (in the LMIC-Arduino folder), pop in your keys and the pins for your board and cross your fingers. Once that’s running you MAY find the original code from the TTN story works, it may not, but we can move this along once we’ve got your radio transmitting.
This is the test rig I built yesterday so it wasn’t tainted by the numerous PCB’s I’ve got:
The unknown event is irrelevant if we are moving over to a different implementation of LMIC. I did look at what it actually was but the issues with Windows have pushed that out of my memory. However as cslorabox says, we still need to pay attention to events as that’s what tells what the stack is up to.
1 Like
Many thanks yet again.
You’ll see on the small white board that I’ve removed the resistors so they don’t interfere with the Hope board. They are required if you are using an ESP8266 or similar WiFi board which is what it was originally designed for.
Underneath there is a place where a voltage reg would go for the ESP module - to allow use of the bottom left pin we need to put a small link in. On my picture this is one of ground pins for the RFM, if the RFM is the other way round, it would be DIO2 which isn’t vital but can be useful. Here’s a picture showing how it needs to be bridged:
No problem - I find it easier to do useful things if they have a recipient / tester.
The small Arduino’s are filled up rather too quickly if you have a sophisticated sensor, multiple sensors or need more ‘intelligence’ but they are a low cost quick build and there is a wealth of support info on things you can attach to them on the inter webs, so I’m motivated to support them for adhoc pieces of work.
It’s clear as mud that bit - if you DON’T choose either one or the other, the next set of lines then choose the SX1276 and then checks you haven’t uncommented both line 47 & 50.
If you use WordPress, you’ll recognise that this is a similar build up of cruft & conflicting additions.
I’m being dim again but I’m struggling to download that LMIC library. There is no download zip button (I believe they have removed it) and because, I assume, it isn’t published I can’t load it from within the IDE as it only shows up to version 2.
Edit: I’m downloading the GitHub Desktop now so will give that a try.
Version 2 is fine - but the zip download is now neatly hidden inside the oval blue-is Code button a bit down on the right.
Just found it - as you say hiding under another button!
It’s working! Because it was quick to do I just compiled the bike tracker code with the new library and it is now transmitting on 868MHz and, wonder of wonders, my new gateway (8 channels no fruit involved) is picking up packets. No low memory warnings either 767 bytes left.
1 Like
I need to do some work on decoding the packets now. I found an example but it doesn’t quite align with the way these packets are put together but it is a start.
But not before tomorrow I think. Time for a break. Very many thanks yet again and no doubt I will have more questions later. 
Just an update. I’ve added the altitude improvement (altitudeGPS>>16) in the code which also required the third line down to be changed from int16 to int32:
int32_t lat = flat * 10000;
int32_t lon = flon * 10000;
int32_t altitudeGPS = faltitudeGPS * 100;
int8_t hdopGPS = fhdopGPS;
channel = 0x01;
coords[0] = channel;
coords[1] = LPP_GPS;
coords[2] = lat >> 16;
coords[3] = lat >> 8;
coords[4] = lat;
coords[5] = lon >> 16;
coords[6] = lon >> 8;
coords[7] = lon;
coords[8] = altitudeGPS >> 16;
coords[9] = altitudeGPS >> 8;
coords[10] = altitudeGPS;
}
Then I found a simple decoder which I amended to include altitude:
function Decoder(b, port) {
var lat = (b[2]<<16 | b[3]<<8 | b[4]| (b[2] & 0x80 ? 0xFF<<24 : 0)) / 10000;
var lng = (b[5]<<16 | b[6]<<8 | b[7]| (b[5] & 0x80 ? 0xFF<<24 : 0)) / 10000;
var alt = (b[8]<<16 | b[9]<<8 | b[10]| (b[8] & 0x80 ? 0xFF<<24 : 0)) / 100;
return {
location: {
lat: lat,
lng: lng,
alt: alt
},
};
}
This seems to work although the altitude figure varies a lot between 95 and 155 (should be 70) but that might be just as a result of a poor view of the sky as it is raining so it is looking through a window.
Curiously, I don’t seem to be able to alter the order they appear, alt is always first, then lat then lng. It seems to want to work in alphabetical order.
What I’m not sure of is should I be doing something with bytes [0] & [1] because the decoder is currently ignoring them?
Where is this LPP_GPS defined? If defined in some library then I’d assume it would also provide functions such as, say, addGPS? Also, if properly encoded using Cayenne LPP then TTN Console can decode for you out of the box, if you select the proper payload format:
That said, assuming coords is some 8 bits data type, then it seems your code looks okay. You don’t need to use the channel in bytes[0] if your device only has a single GPS receiver. Also, you don’t need to validate bytes[1] if you know what you’re sending… In fact, you could also not use Cayenne LPP and not send those 2 bytes, and use a decoder like you did. Altitude could then maybe use fewer bytes too. In all, that would only limit the total payload from 13 + 11 = 24 bytes to about 13 + 7 or 8 = 20 or 21 bytes. (A LoRaWAN packet always needs at least 13 bytes of overhead.)
Aside: please see How do I format my forum post? [HowTo]
Thank you, I’ll have another look later, walking the dog at the moment.
And I’d forgotten there is a format for pasting code. Oops!
EDIT: Just formatted it.
That Cayenne LPP payload format works perfectly, many thanks. This probably explains why in the original article in my first post (OP) there is no mention of decoding.