Cicadacom Structure

Based largely on https://github.com/SteveCossy/IOT/blob/master/PicAxe/Cicadacom LoRaRssi 1910.bas, but tends to vary with each sensor created. (Tables created online from HTML.) 7 Bytes over whatever radio system - ASK or LoRa radio etc.

Synch Header (2 bytes)	Node ID	PicAxe Channel	Low byte of Data word	High byte of Data word	Checksum
':0' synchronises serial input to start of data packet from background noise etc	Single numeric ASCII digit 1 ~ 9 identifies what local Node (generally Pi ) or other 'main system' www connected device	Number allocated to a particular sensor value. Usually will be used for a Cayenne Channel number which might follow the table below	Data low byte full 8 bit binary 0 ~ 255	Data high byte full 8 bit binary 0 ~ 255	XOR single byte made up of = Node_ID XOR Channel_ID XOR L_Data XOR H_Data

Rx End Error Detection: At the RF Rx end these same data are XOR'd with the CS byte and the result will be ZERO = 0 binary IF no individual bits have been corrupted. The H data byte + L Data byte make up a 16 bit word.

Cicadacom Data Representation

Note - this is implemented in the MQTTUtils library.

Data Type	DO / DI	Units	Data Structure	PicAxe Channel	Cayenne Channel	Modification of raw sensor data
Logitude-Deg	Analog Input	Degrees Whole	Int	G	7	Divide by '1*-1' (We are always in Southern Hemisphere!) Max 256
Logitude-dec	Analog Input	Degrees Decimal	Word	H	8	Divide by 60000 (convert betweens seconds and decimals of a degree) Max 65335
Longitude-Deg	Analog Input	Degrees Whole	Int	I	9	Divide by 1 Max 256
Longitude-dec	Analog Input	Degrees Decimal	Int	J	10	Divide by 60000 Max 65335
RSSI from Dorji 1268 module	Analog Input	Varies	Varies	K	11	Divide by 256
Battery	Analog Input	millVolts	Word	L	12	Divide by 1 Max 65335
Button & Switch	Digital Output	Binary	byte	M	13	Divide by 1 Max 500
Slider	Analog Output	percent	byte	N	14	Divide by 1 Max 500
GPS Location	DI	Lat Lon Altitude [List]	gps 'm'	O	15	Needs to be past as a list. Preprocess each part as per Channels G,H,I,J above.
RSSI	DI	float	Byte	V	22	Read from receiving LoRa 1268 module
Temp	AI	float	Word	W		(usually on KeaPatch board)
Light				X
QOS				Y		1-100% maybe based on invalid checksums received
Battery Voltage				Z		Volts DC supply to PicAxe
CPU Temp	DI		Byte	CPUtemp	41	Internal Pi value
Errors	DI		Byte	Status	40	Status Report from Device

The Cicadacom system is completely flexible about channel ID This generally this aligns simple to ID field instruments and devices as Cicadacom A, B, C with Cayenne Channels 1,2,3 etc All Cicadacom communication data handling within the field / picaxe is a word over the radio in any case For the project whether a word or a byte resolution is needed is per use / test case

Lower alpha characters are for 'Sand Pit' testing day to day demo, ease of student simple projects that will come and go.

Channels W,X,Y,Z are generally reserved as system monitoring variables W = local temperature... Is your house on fire etc ( decimal degree C ) X = Local ambient light... Did you leave the lights on in the attic (wobbly relative number ) Y = QoS and is critical to know how good your radio link expressed as 100% over last hour LoRa will most likely pin to 100% all the time Z = Voltage of the Picaxe / Cicadacom Pi supply voltage in mVolts

'Current' sensors:

Updated 2 August 2020

Portable GPS Sensor

Channels 7,8,9,10,11,12 as listed above.

Kihi-01

(1) Moisture (2) Ambient Temp (3) Seq Nbr (4) Solar Batt Lvl

Kihi-02

(19) Kihi-02 Moisture Level inside box (Rh%) (20) Kihi-02 Temp inside box (Deg C) (21) Kihi-02 Sequence Nbr for QOS check (22) Kihi-02 Battery Voltage (mV)

Kihi-04 - Robust GPS

PicAxe (Cayenne) Channels	Function (ref table above)
[ (27)	Logitude-Deg
\ (28)	Logitude-dec
] (29)	Longitude-Deg
^ (30)	Longitude-dec
_ (31)	RSSI
` (32) Battery

ZIP Gateway - internal values

(40) Status-Polybox-64e2ac (41) CPU Temp (43) Load Avg % (44) Disk Used % (45) Wifi Link Quality (46) Wifi Level Quality (47) Ext Temp

Kihi-04 - Robust GPS - Proposed dropping of ASCII characters

PicAxe & Cayenne Channels	Function (ref table above)
65	Logitude-Deg
66	Logitude-dec
67	Longitude-Deg
68	Longitude-dec
69	RSSI
70	Battery

Conversion Table

ASCII (Dec)	PicAxe	Cayenne
65	A	1
66	B	2
67	C	3
68	D	4
69	E	5
70	F	6
71	G	7
72	H	8
73	I	9
74	J	10
75	K	11
76	L	12
77	M	13
78	N	14
79	O	15
80	P	16
81	Q	17
82	R	18
83	S	19
84	T	20
85	U	21
86	V	22
87	W	23
88	X	24
89	Y	25
90	Z	26
91	[	27
92	\	28
93	]	29
94	^	30
95	_	31
96	`	32
97	a	33
98	b	34
99	c	35
100	d	36
101	e	37
102	f	38
103	g	39
104	h	40
105	i	41
106	j	42
107	k	43
108	l	44
109	m	45
110	n	46
111	o	47
112	p	48
113	q	49
114	r	50
115	s	51
116	t	52
117	u	53
118	v	54
119	w	55
120	x	56
121	y	57
122	z	58
123	{	59
124	|	60
125	}	61
126	~	62

Cicadacom Channel Processing

Note that these comments, written 21 Jan 2022, are based on my memory from a year or two ago. Read with care! Steve

Andrew used a very long chain of if statements to:

• Convert the text string data received from the PicAxe into a float. 'data' variable. Some channels required the raw data to be divided by a 'Divisor' to make it usable. This is implemented in Steve's code within the LoRa_to_MQTT module.
• The 'Channel' being used for the current packet is in ASCII in the PicAxe, read by Python as a string.
• Check that the data value is not outside a reasonable value for that channel, which can be different for each channel depending on what that channel was being used for in a particular situation. If the data value is outside the test, then write a null value to the MQTT broker and break out of the client processing loop. ('client.loop()')

I believe that the DivisorDict and ChannelMap dictionaries are a mess. They are unwieldy, poorly thought out, and generally loose. I do think they are better than 30-odd if statements!

I can't remember offhand what Serial_to_MQTT uses for this. I suspect it is something like Save2Cayenne (ref ChannelMap above), and I would welcome a tidier solution! I believe the tidiest solution would be to build a TOML file that contains all channel-related data, read by whatever modules need it, but I suspect that is out of scope for the current state of this project.

I can't help with the channel numbers, but do recall making notes about that - perhaps our last workshop at Zealandia? Sorry - can't find my notes right now!