Escort Data Logging Systems MINI PORTABLE DATA LOGGING DEVICE User Manual Wireless Mini technical manual v1 3

Escort Data Logging Systems Ltd PORTABLE DATA LOGGING DEVICE Wireless Mini technical manual v1 3

USERS MANUAL

Wireless Mini Technical manual Implant Rev 1.2 Revision History Rev 1.0 - WCH 25/5/5 Rev 1.1 - WCH - 2/8/5 Rev 1.2 - WCH - 13/9/5 Rev 1.3 - WCH - 29/11/5 This manual covers the functionality of the RF circuitry (referred to as 'The RF Implant') in the Wireless Mini. For details of the logger circuitry and functionality please refer to the LCD Mini technical manual.
1 - Contents - 1.0 General description 1.1 Sleeping & Waking 1.2 Interfacing to the host system 1.3 Battery measurement 1.4 Local copies of information 1.5 In circuit serial programming 2.0 RF description 2.1 Hardware 2.2 Packet structure 2.3 Resynchronisation 3.0 Packets and Protocols 3.1 Packet formats 3.2 Specific packet types 3.3 Establishing communications 3.4 Reading data from a logger 3.4.1 The read process 3.4.2 Packets associated with reading the log buffer 3.5 Writing to a logger 3.5.1 The Write process 3.5.2 Packets associated with the write process 3.5.3 The program data structure 3.5.4 Restarting loggers with version 1.6 firmware 3.6 Security settings and Lease count 3.7 Status request 4.0 Code description 4.1 Breaking out of non-terminating loop 5.0 Memory map 5.1 Constants
2 Revision History 1.2 Status Reply packet type corrected (was 0x14, now is 0xF1) 1.3 GoToSleep packet introduced (packet 0x18)
3 1.0 General description The Wireless Mini is designed around the LCD Mini. In essence it incorporates a complete LCD Mini logger with an "RF Implant" attached. The code and functionality of the logger part are identical to the LCD Mini and the Implant simply allows data to be extracted via RF rather than direct connection. To this end the original code running on the Oki processor of the LCD Mini is 'unaware' of the RF circuitry and makes no allowance for it. The Implant, which is based around a PIC microcontroller, must trick the Oki processor into leaving the EEPROM alone when it wants to access it. This is detailed in section 1.2. The RF circuitry consists of two main blocks namely a PIC microcontroller and an RF transceiver (RFM TR1000/TR1001). This technical manual will discuss this circuitry and refer to it as the "Implant". For details of the logger part of the product please refer to the LCD Mini technical manual. The Implant has been designed so that it may be converted to add RF functionality to other products (e.g. iLog). It has been designed to be highly portable although some code modification will inevitably be necessary. The Implant is designed to be part of a multi-node network with one Master and many loggers. Obviously only one device can be transmitting at any one time but all loggers will be listening to all packets and will respond when uniquely addressed. The unique address is based on the logger's type and serial number. 1.1 Sleeping & Waking To be able to provide high speed communication over a respectable range the RF Implant processor must run at 4MHz and the RF receiving circuitry must be very sensitive, however the whole system must also draw less than 100uA. To achieve this it spends most of the time sleeping then for 4ms every 1/3 of a second it wakes up and listens for signal. If it receives a valid signal it will enter 'Active' mode where it is continuously listening. The cyclic wake up circuitry is simply a capacitor charging through a resistor (R23 and C15 on Rev 1.0 schematic). When the voltage on the cap. passes a threshold it triggers an interrupt to the PIC which pulls it out of sleep mode. The PIC in turn pulls the transceiver out of sleep mode and begins listening. At the same time it discharges the capacitor through R24. If a valid signal is not received within 4ms then the now discharged capacitor is released to begin charging again, the PIC goes to sleep and cycle repeats. A valid signal is defined as a complete WakeUp packet. The protocols are defined in Section 3.0. When another device, the Master, wants to find out what loggers are within range it broadcasts a series of Wake Up packets to all loggers. All loggers within range should hear at least one of these and enter Active mode. With the loggers attention it then broadcasts WhosThere? and the loggers reply in randomly selected time slots. The loggers identify themselves using a unique address and from then on the Master uses this to direct commands to individual loggers. While in active mode, if the logger does not detect any valid packets for a period of 60s then it switches back to its low power mode and begins the sleeping / waking process again. 1.2 Interfacing to the host system The LCD Mini was designed to communicate with other devices via RS232 at 2400 baud. This is far too slow for the purposes of radio communication. To get around this the Implant uses direct memory access to
4 the EEPROM. This however requires a trick because the Oki processor is unaware of the Implant so makes no allowance for memory sharing. Fortunately the Oki code will not access EEPROM when it is in 'comms mode'. When the Oki processor gets a message via RS232 it finishes any activities it is part way through then enters comms mode. While in this mode it does nothing more than monitor the comms lines and update its RTC. If there is no activity on the RS232 lines for 800ms or more then it resumes normal operation. When high speed reading of the EEPROM data is required, the Implant exploits this functionality by sending a message via RS232 to the Oki processor. Once it is satisfied that the Oki processor has entered comms mode, it directly accesses EEPROM at high speed. Each block of 64 data bytes is transferred to local PIC RAM, assembled into a packet then transmitted out over the RF link. After a valid 'Ack' is received from the Master the next packet is retrieved, assembled and sent. Because the Oki processor was originally set up to be the exclusive master on the I2C bus it is necessary to convert the the output driving the SCL line into an open collector port before attempting to drive it with another processor. This is done using two schottkey diodes (D2 & D7 on rev 1.0 schematic). In the same way the RS232 is driven as open collector with the PC driving Q4 and the PIC driving Q7. There are other blocks of information which can be read once, when no RF activity is occurring, and stored for later (such as the loggers serial number) and the Implant simply uses the normal RS232 channel for this. There are further pieces of information such as the loggers current logging state which need to be read in real time but don't require DMA and again the RS232 channel is used for this. If a PC is trying to access the logger via RS232 at the same time as the Implant then there will be contention. This is unavoidable but will be detected by corruption of the check-sum. To alleviate any problem here the Implant will refuse to operate if the logger is connected to a PC. It monitors the power supply to the RS232 circuitry (through the voltage divider R28 & R29 on rev 1.0 schematic) and if this is on then it will switch from active mode to sleeping/waking mode (if active to start with) and will not respond to any 'WakeUp' commands that are broadcast. 1.3 Battery measurement The battery measurement of the Wireless Mini logger is based on battery voltage and is simply a Good/Bad measurement. The battery measurement circuit in the original LCD Mini is reasonably poor. It is only approximate at room temperature and changes significantly with temperature. This has not been a major problem with this logger as the battery can only be measured when the LCD Mini logger is connected to a PC and this generally is at room temperature. With the inclusion of RF communication the logger may now report its battery status when the logger itself is at any temperature in its range. To ensure an accurate measurement the Implant uses a separate circuit based around a dedicated IC. This device, U3 - TC54, will output a high voltage when its input is greater than 2.7V and a low voltage when its input is less than 2.7V. The output of this device is connected to an input on the PIC. In addition to this there is a voltage divider at the input of the device (R33 & R34) which divides down the battery voltage. Every time the Implant reads the battery level it switches this divider in, reads the level, then switches this divider out to save current. The values of the resistors can be adjusted to set the level at which the battery is considered to be getting low. The battery is measured every time a Status packet is requested.
5 Note that the Oki processor still uses the original method of measuring the battery level. Although checked for accuracy in the factory it is possible that the two battery level circuits may report conflicting levels. Note also that irrespective of the remaining energy, the voltage on the battery will vary significantly with temperature. 1.4 Local copies of information To ensure a high speed response the Implant must reply to any requests from the Master as soon as it can (within a few milliseconds if possible). As mentioned in section 1.2 the Oki processor only communicates via RS232 at 2400 baud. In addition to this there may be as much as 1.5 seconds delay before it enters comms mode after receiving an RS232 packet. Due to this the Implant makes local copies of some of the logger information so that it can provide expedient replies to any Master that is talking to it. The most notable of these is the serial number. Immediately after power up the Implant reads the loggers serial number (via the RS232 channel) and stores it in local RAM. From then on it uses this as part of its unique address. The Implant has an input which tells it if the logger is connected to a PC or not. If the Implant detects that it is then it will begin monitoring the line. After 2 seconds of inactivity from the PC the Implant will ma ke a local copy of the security settings. When an attempt is made to restart or reprogram the logger via RF then these local settings are used to allow or deny the command. Note that it is possible to change a loggers serial number by writing to EEPROM while the local copy in the Implant remains unchanged. This could cause great confusion. To avoid this it is necessary to power cycle the logger any time its serial number is changed. Variable that is copied When it is copied Serial number Immediately after power up After a watch dog restart Case type Immediately after power up After a watch dog restart Oki code f/w version Immediately after power up After a watch dog restart Lease state Immediately after power up After a watch dog restart 2s after PC comms cease (f/w version 1.7+ changes this to 1s) When requested by a 'CheckLeaseState' packet User flags Immediately after power up After a watch dog restart 2s after PC comms cease (f/w version 1.7+ changes this to 1s) Security code Immediately after power up After a watch dog restart 2s after PC comms cease (f/w version 1.7+ changes this to 1s) Table of local copies of logger information 1.5 In circuit serial programming At this stage the Implant is not specifically set up for ICSP however the PIC processor supports this and the PCB can also accommodate it.
6 Removing R44 and installing D11 will isolate the supply and with a suitable clip to go over the PIC processor ICSP can be implemented. D10 will isolate Vpp from the rest of the circuitry. Initially the supply line of the PIC is connected directly to the power supply simply to remove a diode drop and increase reliability under low battery conditions.
7 2.0 RF description 2.1 Hardware The RF Implant uses Amplitude Shift Keying (ASK) i.e. a logic high is represented by a high amplitude of the RF frequency and a logic low is represented by a low (but not zero) amplitude of the RF frequency. The ASK drive signal that the transceiver module requires is a current based signal and must switch between a higher current and a lower (but non-zero) current. This is produced by two digital outputs from the PIC microcontroller (RA1 & RB5). These two outputs have weighted resistors and the current is switched to high with both outputs high and low with RA1 low and RB5 high. Both outputs sit low when not transmitting. The data rate is 83k333 baud which is exactly 12us per transmitted bit. Manchester encoding is used so every bit is sent as two 'transmitted bits', first the bit itself then second the inversion of the bit. This keeps the signal DC balanced (a requirement of the transceiver) and allows for 100% error checking. The data flow, for obvious reasons, is half duplex. The transceiver module must be switched between transmit and receive mode depending on the data direction. This is achieved by RB6 & RB7. Both low turn the transceiver off. Both high put the transceiver in receive mode. RB6 low and RB7 high put the transceiver into transmit mode. The transceiver simply converts the current into its digital input to RF energy when transmitting or the RF energy (after automatic gain adjustment) into a voltage at its digital output when receiving. It does not attempt to interpret or encode the data bits. To this end there is no auto detection interrupt when in receive mode so the PIC must be checking the data (or noise) stream when it is expecting a packet. The data bits are bit-bashed both in the Implant and in the REDi. The data rate is independent of the RF frequency. Initially there are two RF frequencies namely 916MHz for the US market and 868MHz for the European market. The oscillator for the specific frequency is built into the transceiver so to convert a logger from one frequency to the other would require changing the transceiver. No PIC firmware changes would be required. With the inclusion of L2 (10nH) and L3 (100nH) inductors at the RF I/O pin of the transceiver, the module is matched for a 50Ω real impedance. The network L4 and C26 is required to match the antenna itself to this impedance. The sensitivity of the receiver is 91dBm. The power of the transmitter is 1.5dBm. This, given the losses in the system, allows for a transmission range of around 50m outdoors.
8 2.2 Packet structure The data is clocked LSB first. The diagram below shows a command packet .. The Implant first polls for at least 11 bits of the preamble then for an exact match of the start character (refer to section 5.1). If this match is found then it continues to clock in the rest of the packet. As it does this it checks each bit for correct Manchester encoding and aborts if it sees corruption. Finally it checks the checksum then processes the packet. The logger type and serial number form a unique address. The serial number is simply a copy of the loggers electronic serial number and the LType is a number referring to the product. For all transfers this is used to identify the logger that is being addressed or is replying. The assumption is that there is only one Master and it is always part of the communications. Attempting to use two REDi Masters at once will lead to interference and failure to communicate. Interlaced use of two REDi Masters in the same proximity should work as expected. For a general broadcast to all loggers the address 0xFF,0xFF,0xFF,0xFF,0xFF is used. The packet type identifies the purpose of the packet. The packet length can be inferred from this although in practice the Implant (or REDi) will be expecting a certain type of packet and assumes the length before it begins clocking bits in. This is done because the processor is not powerful enough to decode the packets on the fly. If a longer or shorter than expected packet is sent then the check sum will not add up and the packet type will be wrong leading to the packet being rejected. The Data section is the relevant content of the packet and varies from packet to packet. This is detailed on the following pages. The Checksum is the check sum for the whole packet excluding the preamble. It is a 16 bit Fletchers check sum. This is not as robust as CRC but is significantly faster to generate and check and in fact is barely necessary given the inherent error checking properties of Manchester encoding. 0xAA 0xAA 0xAA STX0 STX1 LType S/N S/N S/N S/N Data Data PType Data Data Data Data FCS0 Padding Padding FCS1 Preamble to condition the Automatic Gain Circuits 16 bit start character Resynchronisation edges to ensure bit timing is accurate Packet type Check sum. Fletchers used because it is fast - most error checking done on a per bit basis. To simplify the coding packets are always multiples of 4 bytes plus one 5 byte block.
9 2.3 Resynchronisation Although Manchester encoding inherently contains a clock signal the processors (PIC and M16) are not fast enough to extract this on the fly and use it to adjust their timing. To this end the signal is treated as asynchronous and the timing is based around the system crystal. After every four bytes a synchronisation edge is sent which is used to bring things back into line if there has been drifting. The calculation for this is shown. 4 bytes x 8 symbols x 2 bits x 12us = 768us 1/2 bit width = 6us 6 out of 768 = 1 part in 128 = 7812ppm if accuracy is 50ppm/ °C then : -40°C to +25°C = 65°C x 50ppm/°C => 3250ppm = 0.21 bit width absolute accuracy of ±50ppm at 25°C is of negligible importance (gets swamped by the drift)
10 3.0 Packets and Protocols While the general structure of each packet is the same, several different packets have been defined based on the length and type of data to be transferred. The packet types are shown below followed by tables of specific packets. 3.1 Packet formats Wake Up packet: Field name # bytes Field content Preamble 3 0xAA,0xAA,0xAA Start character 2 0x72, 0x65 Packet type 1 0x00 - Wake up Check Sum 2 0x06, 0x22 - Fletcher Command packet : Field name # bytes Field content Preamble 3 0xAA,0xAA,0xAA Start character 2 Recipient 5 TSSSS (Logger Type, Serial Number) Packet type 1 Variable Data 6 Always 6 bytes in length Check Sum 2 Fletcher Very Short Data Packet : 4224us Field name # bytes Field content Preamble 3 0xAA,0xAA,0xAA Start character 2 Logger / Recipient 5 TSSSS (Logger Type, Serial Number) Packet type 1 0xF0 Data 6 Always 6 bytes in length Check Sum 2 Fletcher Short Data Packet : Field name # bytes Field content Preamble 3 0xAA,0xAA,0xAA Start character 2 Logger / Recipient 5 TSSSS (Logger Type, Seria l Number) Packet type 1 0xF1 Data 32 Always 32 bytes in length Check Sum 2 Fletcher
11 Long Data Packet : Field name # bytes Field content Preamble 3 0xAA,0xAA,0xAA Start character 2 Logger / Recipient 5 TSSSS (Logger Type, Serial Number) Packet type 1 0xF2 Data 48 Always 48 bytes in length Sequence 4 Packet number (LSB first) Check Sum 2 Fletcher Very Long Data Packet : 16464us Field name # bytes Field content Preamble 3 0xAA,0xAA,0xAA Start character 2 Logger 5 TSSSS (Logger Type, Serial Number) Packet type 1 0xF3 Data 64 Always 64 bytes in length Sequence 4 Address where this data has come from (LSB first) Check Sum 2 Fletcher Single Byte Reply : Field name # bytes Field content Preamble 3 0xAA,0xAA,0xAA Start c haracter 2 Logger 5 TSSSS (Logger Type, Serial Number) Packet type 1 Variable (Ack, Nack etc.) Check Sum 2 Fletcher
12 3.2 Specific packet types REDi to Logger Name Packet ID (PType) Packet Type Recipient Data Description Wake Up 0x00 Wake up Non specific none Broadcast over and over for 1 second to wake up all loggers. Ack 0x01 Single Byte Reply TT,SN,SN,SN,SN none Acknowledgement of correct reception of a packet. Resend 0x02 Single Byte Reply TT,SN,SN,SN,SN none Request for a retransmission of the last packet. Who's There ? 0x11 Command 0xFF,0xFF,0xFF, 0xFF,0xFF all blank Request for loggers to identify themselves. Don't reply to "Who's There ?" 0x11 Command TT,SN,SN,SN,SN all blank Tells the specified logger not to reply to the general "Who's There ?" packet. Read Data 0x12 Command TT,SN,SN,SN,SN D[0:2] : address to read from D[3:5] : length required Request for the logger to begin sending a series of data packets. Status Request 0x14 Command TT,SN,SN,SN,SN all blank Request for the loggers status packet. How much data do you have ? 0x15 Command TT,SN,SN,SN,SN all blank Request for the size of data that the logger holds. Program Logger 0x16 Command TT,SN,SN,SN,SN D0 : # of packets that follow D1 : flags D[2:5] : security code The command to initiate reprogramming or restarting a logger. "Logger Program" packets may follow this. Check Lease Count 0x17 Command TT,SN,SN,SN,SN all blank Request for the logger to check the lease count now. Go To Sleep 0x18 Command TT,SN,SN,SN,SN or 0xFF,0xFF,0xFF, 0xFF,0xFF all blank Puts a specified logger or all loggers within range to sleep. (introduced after version 1.9 f/w) Logger Program 0xF2 Long Data TT,SN,SN,SN,SN See section 3.5 on programming a logger. Data packets containing the data and locations of a loggers program. Logger to REDi Name Packet ID (PType) Packet Type Data Description Ack 0x01 Single Byte Reply none Acknowledgement of a correctly received packet. Nack 0x03 Single Byte Reply none The packet was received but was not or cannot be processed. [no longer used] Bad Password 0x04 Single Byte Reply none Reply when a "Program Logger" packet was received and the logger required a password and the password was incorrect. Lease Expired 0x05 Single Byte Reply none Reply when a "Program Logger" packet was received but the logger's lease had expired. Data Request Reply 0xF3 Very Long Data Packet 64 bytes of logger data A block of data read out of the logger's EEPROM. Data Size Reply 0xF0 Very Short Data Packet D[0:2] : data length D[3:5] : start address Reply to the "How much data do you have ?" packet. Status Reply 0xF1 Short Data Packet D[0:1] : Implant f/w D[2:3] : Logger f/w D4 : Case type D[5:22] : Status packet from host logger Reply to a Status Request packet. See section 3.7.
13 D[23:end] : padding All multi byte quantities have MSB at the highest address.
14 3.3 Establishing communications The Master (REDi) transmits 'Wake Up' repeatedly for 1.0 second. The logger listens for 4ms roughly every 330ms. The wake up packet takes 1.5ms to transmit so this ensures a minimum potential of six 'Wake Up' messages received if within range. For firmware verison 1.7+ the logger actually spends a few hundred microseconds prior to this analysing the incident RF energy to determine if it looks like a stream of data at the correct rate. If it does then it continues to poll for 4ms for a 'Wake Up' message. If it doesn't then it goes straight to sleep. If the logger gets a 'Wake Up' packet it remains Active (listening) for the next 60 seconds. In fact it remains active for 60s after the last valid packet it receives. All loggers within earshot should now be Active (continuously listening). If only new loggers are required then ... The REDi scans its database and broadcasts 'Don't reply to "Who's There?"' to all known loggers (whether in range or not). The 'Don't reply to "Who's There?"' command is identical to the 'Who's There?' command except that the former has a specific address associated with it and the latter has the address section set to all 0xFF to indicate a general broadcast. If a logger receives a 'Don't reply to "Who's There?"' command (addressed specifically to it) then it will ignore any general broadcasts of 'Who's There?' for the next two seconds. The REDi then broadcasts a general 'Who's There?' command. If the logger receives a 'Who's There?' command then it randomly selects a time slot (32 slots spaced 8ms apart) and responds by transmitting three 'Ack' packets one after the other. The 'Ack' packets contain the logger's type and serial number and uniquely identify that Logger. If the REDi receives one or more of these packets then the logger is added to a list of 'Loggers within range'. After listening for 256ms (32 x 8ms) the REDi transmits the 'Don't reply to "Who's There?"' command to each logger in the 'Loggers within range' list. The REDi then broadcasts a second general 'Who's There?' command and the process is repeated. After this a third cycle is performed. After 1.77s the establish comms procedure is complete and we are ready to start transferring data from individual loggers.
15 3.4 Reading data from a logger 3.4.1 The read process To download the logger's log buffer the REDi controls a sequence of steps. The REDi always acts as the Master and the logger as a Slave. If the REDi does not get a valid reply during any step it will retransmit the request up to 15 times. Step 1 The REDi first broadcasts a 'How much data do you have ?' command. The logger responds with a 'Data Size Reply' packet containing the size and start address. Step 2 The REDi then broadcasts a request for this much data. The logger replies with an 'Ack'. The logger also takes a snapshot of its internal status at this point. Step 3 The REDi then transmits a 'Resend' command. The logger responds by sending the first Data packet back. If this is received correctly the REDi sends an 'Ack'. If this is not received or is corrupt the REDi sends a 'Resend'. If the logger gets a 'Resend' it sends the same packet again. If the logger gets an 'Ack' it sends the next packet. If the REDi sends an 'Ack' which the logger does not receive then, after not receiving the next data packet, the REDi will follow this with a 'Resend' and will get the previous packet again (which was correctly received last time). All packets have an associated sequence tag which alerts the REDi to ignore the second transmission. Both the logger and the REDi keep track of how many packets are sent. When the logger sends the last packet (and gets a valid 'Ack') it simply stops and goes back to listening for Command packets. Step4 The REDi sends a 'Status Request' command. The logger responds with a 'Status Reply'. Note: The REDi sends only a generic Ack to get the next packet instead of acknowledging each sequence number and specifically requesting the next. This is to keep overhead to an absolute minimum.
16 3.4.2 Packets associated with reading the log buffer How much data do you have ? (REDi to Logger) : Field name # bytes Field content Preamble 3 0xAA,0xAA,0xAA Start character 2 0x72, 0x65 Recipient 5 TSSSS (Logger Type, Serial Number) Packet type 1 0x15 Data 6 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 Check Sum 2 Fletcher Data Size Reply (Logger to REDi) : Field name # bytes Field content Preamble 3 0xAA,0xAA,0xAA Start character 2 0x6C, 0x67 Logger 5 TSSSS (Logger Type, Serial Number) Packet type 1 0xF0 Data 3 3 Data length (LSB first) Data address (LSB first) (always EEPROM) Check Sum 2 Fletcher Read Data (REDi to Logger) : Field name # bytes Field content Preamble 3 0xAA,0xAA,0xAA Start character 2 0x72, 0x65 Recipient 5 TSSSS (Logger Type, Serial Number) Packet type 1 0x12 Data 3 3 Data length (LSB first) Data address (LSB first) (always EEPROM) Check Sum 2 Fletcher Data Request Reply (Logger to REDi) : Field name # bytes Field content Preamble 3 0xAA,0xAA,0xAA Start character 2 0x6C, 0x67 Logger 5 TSSSS (Logger Type, Serial Number) Packet type 1 0xF3 Data 64 Data Sequence 4 Address of data byte #1 in this packet (LSB first) Check Sum 2 Fletcher
17 3.5 Writing to a logger 3.5.1 The Write process The REDi sends a 'Program Logger' command which contains a security code. If the logger is leased and the lease has expired then the logger replies with a 'LeaseExpired' packet and returns to listening for command packets. In fact the lease count must be checked at the time of reprogramming because the logger may be in the Ready or Logging state and this may affect whether it can be reprogrammed. See section 3.6 for more detail. If the Master (REDi) gets a 'LeaseExpired' reply then it should send an 'UpdateLeaseCount' packet then try the 'Program Logger' command again. If the logger is password protected for programming and the security code does not match the loggers code then it replies with a 'BadPassword' packet and returns to listening for command packets. If the security code etc. is valid then the logger replies with an 'Ack'. The logger then decodes the command packet to determine if there are packets to follow. There could be up to 3. If no further packets are expected then the logger gets on with processing the flags. If further packets are expected then the REDi sends each one in turn. The logger replies to each packet with an 'Ack' if received correctly. Once all packets are received they are processed in reverse order. Packet #3 is processed first, then #2, then #1 then the flags in the original command packet are processed. For firmware version 1.7+ a flag called 'LastProgramOK' is cleared as soon as a 'Program Logger' command is received. If the program gets correctly implemented (ie. the Oki processor acknowledges all packets sent to it and the PIC code completes the reprogramming loop) then this flag is set. It is available in the 'Status' packet and should be checked by the REDi Master after reprogramming a logger. For firmware version 1.6 the REDi Master must read back the lower 64 bytes of EEPROM and check the signature of the program to verify correct implementation. 3.5.2 Packets associated with the write process The Program Logger packet Field name # bytes Field content Preamble 3 0xAA,0xAA,0xAA Start character 2 0x72, 0x65 Recipient 5 TSSSS (Logger Type, Serial Number) Packet type 1 0x16 Data 6 [ Note 1 ] Check Sum 2 Fletcher
18 Note 1 : Data structure byte 0 number of packets to follow (only lowest 2 bits recognised so max. 3 packets) byte 1 flags [ Note 2 ] byte 2 SecurityCode#0 byte 3 SecurityCode#1 byte 4 SecurityCode#2 (not used in Wireless Mini) byte 5 SecurityCode#3 (not used in Wireless Mini) Note 2 : Flags bit 0 Load default values into logger registers [ Note 3 ] bit 1 Start the program waiting for button bit 2 Simulate the press of a button to begin the program bit 3 Spare bit 4 0 (note these higher bits must be zero and cannot be used) bit 5 0 bit 6 0 bit 7 0 Note 3 : The default values to load NumberOfLogsTaken = 0x00 TimeOverTemperature = 0xAA,0xA0,0x00 CurrentLogAddress = 0x00B4 TimeUnderTemperature = 0xAA,0xA0,0x00 UpperAlarmCounts = 0x00 HighestLog = 0x00 LowerAlarmCounts = 0x00 LowestLog = 0xFF AlarmControl = 0xF- SumOfAllLogs = 0x00,0x00,0x00 Followed by 0 to 3 Long Data Packet(s) : Field name # bytes Field content Preamble 3 0xAA,0xAA,0xAA Start character 2 0x72, 0x65 Logger 5 TSSSS (Logger Type, Serial Number) Packet type 1 0xF2 Data 48 Always 48 bytes in length [ Note 4 ] Reference 4 Packet number 0,1 or 2 (only one byte used) Check Sum 2 Fletcher Note 4 : Data structure # bytes Description 2 Address (LSB first) 1 Length N variable length data 2 Address 1 Length N variable length data 2+1+N further Address,Length,Data sections
19 2 0x00, 0x00 - zero Address 1 0x00 - zero Length to denote no more data bits 5-0 of the Length byte hold the length of the data to be written. bits 6 & 7 of the Length byte clear means write to EEPROM bit 6 of the Length byte set means the data is an RS232 packet bit 7 of the Length byte set (and bit 6 clear) means write to logger RAM. if Length = 0x00 then there is no further information in this packet 3.5.3 The program data structure The data structure allows the REDi to randomly write to EEPROM or RAM or to simulate an RS232 packet. Direct writes to EEPROM or RAM must be closely checked against firmware version. To write to EEPROM or RAM the Address (LSB first) is specified and the Length of the data. The logger then treats the following bytes in the data section of the packet as the sequential data that will be written to Address, Address+1, Address+2 etc. up to the number specified by Length. The next two bytes in the data section of the packet are then treated as a new Address followed by a Length and data and so the processing continues. When either the end of the data section is encountered or a Length of 0x00 bytes is seen the processing of that packet is finished and the next packet (if there is one) is started. If bit 6 in the Length is set then the following data is treated as a complete RS232 packet and clocked to the logger through the RS232 channel verbatim. This can be used in situations such as the iLog 'resource management' packets where the actual internal address may not be available. There is no read-modify-write ability in this system so modifying some of the bits in a byte while leaving others unaffected is not possible. 3.5.4 Restarting loggers with version 1.6 firmware Version 1.6 loggers have a bug in them. The watchdog period is specified as typically 2.3 seconds however the minimum timeout is specified as 0.9s. The watchdog timer is only cleared in the main loop (while polling for incoming packets) and in the read loop when clocking out the contents of the data buffer. A short watchdog period will generally not be a problem except if a complex reprogram command is sent. If a logger is sent a full reprogram command then it will stop the Oki processor and get it into comms mode, load default program settings, trigger a SemiInit command (waiting 1000ms for this to be actioned) then stop the Oki processor again and write to the Oki action flags to trigger the program to start. All this will take time and it is likely that the PIC watchdog will trigger during the process. To work around this the REDi must put the Oki into comms mode first by sending a non-reprogramming related command then send the reprogram command without the TriggerStartButton flag set. Finally it must send the TriggerStartButton command once all else is done. In addition to this it may be possible for a PIC with a very short watchdog period to be reset when sent a command at the very end of it's 1/2 second polling period and just as the Oki processor begins taking a measurement while the temperature is below 4°C. In this case the logger will not action the command and the user will be informed. This is a rare case and subsequent attempts at communication should work fine. For firmware version 1.7 onward the watchdog timer is cleared in sufficient places such that this problem is eliminated. 3.6 Security settings and Lease count To avoid lengthy delays when reprogramming the Wireless Mini via RF, local copies of the security settings are kept in PIC RAM. Any time that the logger is connected to a PC, however, the user may change
20 these settings in EEPROM. To get around this the RF Implant monitors the power supply to the RS232 circuitry and when it sees activity start then cease it starts a counter. Two seconds after comms activity has ceased, the PIC copies the two bytes of SecurityCode (four BCD digits) to local RAM. It reads the UserFlags and makes a note of whether the program is protected by password or not. It also reads the LeaseControl byte and if the logger is leased then regardless of the lease count it sets an internal flag saying that the lease has expired. When it receives a 'ProgramLogger' packet it will check its internal flag to see if the lease has expired. If it is a leased logger then it will believe that it has and will reply with a 'LeaseExpired' packet. This may or may not be true. The Master should then issue a 'CheckLeaseCount' packet and, after a valid 'Ack', try to program a second time. If the logger reports 'LeaseExpired' a second time this must be believed. This all seems horribly complicated but the problem with lease count is that the Oki firmware is oblivious to it. This means that the device which reprograms it (PC, ChartReader or RF Implant) must decide, based on the logging state and leasecount, whether to allow another trip or not. The rule is that if a program has been loaded but not started then the lease count is not decreased and another program can be set. If the program has been started then the lease count should be decreased, and only if it is now greater than zero should a new program be allowed. As the logger can be started at any stage by the user pressing the button on the logger, the logging state must be checked at the time of reprogramming. Once passed all this the Implant will check the ProgramProtected flag and if so it will check for a password match. If the password doesn't match it will reply with a 'BadPassword' packet otherwise it will get on with clocking in any subsequent packets and reprogramming the logger. If the logger was in a state other than Ready then the TripCount is increased when a program is set and if the logger is leased then the LeaseControl cycle count is decreased. Note: As of version 1.6 of the firmware it is possible to change security settings using a PC, then before two seconds have elapsed, connect to the logger using RF and attempt to reprogram. The new settings will not have been copied to local RAM. After RF comms cease (after 60s of inactivity) and the Implant returns the waking/sleeping mode where the balance of the two seconds will elapse and the settings will then get copied. This is unlikely to cause any serious problem but could be improved in future firmware versions. 3.7 Status request The Status Reply packet Field name # bytes Field content Preamble 3 0xAA,0xAA,0xAA Start character 2 0x6C, 0x67 Logger 5 TSSSS (Logger Type, Serial Number) Packet type 1 0x14 Data 32 D0 : low byte of Implant f/w version D1 : high byte of Implant f/w version D2 : low byte of Oki f/w version D3 : high byte of Oki f/w version D4 : case type D[5:22] : Status packet from host [ Note 1 ] D[23] : Wireless Mini Status flags [ Note 2 ] D[24:31] : padding Check Sum 2 Fletcher
21 Note 1 : For the Wireless Mini the 'Status packet from the host' contains the 18 bytes from RAM nibble address 0x8C to RAM nibble address 0xAF inclusive. These bytes are copied from the Oki RAM to the PIC RAM at the start of a 'Read Data' transfer. If the Master (REDi) issues a 'Status Request' immediately after downloading the loggers log buffer then this packet will contain a snapshot of RAM synchronised with the EEPROM data. If it issues a 'Status Request' at any other time then it should only look at the non-changing constants such as firmware version. Note that the logger measures the battery level at the time that it forms the 'Status Reply' (not when it sends it) and does this by using the new improved battery check circuit not the one the Oki processor uses. Using this result it then sets or clears the flag (ActionFlags1.BatteryStatus) in the snapshot of RAM regardless of its original value. If this module gets integrated into the iLog then the 'Status packet from the host' will contain the standard 12 byte Status reply padded to 18 bytes with zeros. Note 2 : Status flags (introduced from firmware version 1.7 onward) Flag # Description 0 Unused 1 Unused 2 Unused 3 Unused 4 Unused 5 Last Reprogram command executed successfully 6 Unused 7 Unused
22 4.0 Code description The code is written in PIC assembler and is split into several sections as shown. Name Description Radioi.equ The equates file for all further sections. Contains memory map and constants. Radioi.asm The main file. Contains : device initialisation coming out of sleep mode random time slot identification of logger checking for valid packets in 'Active mode' going to sleep breaking out of non-terminating loop Transmit.asm Contains : calculation of check-sum bit-bash clocking out of packets Receive.asm Contains : polling for start characters clocking in of variable length packets (bit by bit) calculation and comparison of check-sum checking - is packet structure valid, is it for this logger Process.asm Contains : processing of "Who's There ?" packet processing of "Read Data" packet processing of "Program Logger" packet checking of lease count etc. processing of "Status Request" packet makes local copies of some EEPROM data processing of "How much data do you have ?" packet functions to move data blocks within memory reading and writing via RS232 i2c.asm Contains : I2C reading and writing functions read function can handle sequential as well as addressed reads 4.1 Breaking out of non-terminating loop Believe it or not this works but is a little unconventional. When polling for an RF start edge the processor is not fast enough to accurately respond to an edge if it is also checking a TimeOut counter. Due to this the logger uses a non-terminating loop to poll for the edge and relies on an interrupt to break it out. Because there is no "pop" instruction this gets a little complex. The way its been achieved is by the original calling function loading a return value (arbitrary but unique number) into the "ReturnFromPFP" file register and using a "goto PollForPacket" instead of a call. When the PollForPacket function needs to return, w is loaded with this value from the "ReturnFromPFP" file register and the "ReturnFunction" is jumped to. The "ReturnFunction" then interprets w and jumps back to the original place where we started from. If the loop times out and the interrupt is triggered this same method is used and no "retfie" instruction is executed. This means the stack can get out of sync but as long as we jump back to the main loop which is the top of the tree for returning then this doesn't matter. The stack can also get out of sync when, during the processing of commands, the code encounters an abnormal condition. In some cases the code may use "goto WereInBusiness" to abort everything and go back to polling for more commands. This does not cause a problem even if that code was originally called as this is the highest level and will execute no further returns.
23 5.0 Memory map (RAM) Address Bank0 Bank1 Bank2 0 System Registers System Registers System Registers 1 System Registers System Registers System Registers 2 System Registers System Registers System Registers 3 System Registers System Registers System Registers 4 System Registers System Registers System Registers 5 System Registers System Registers System Registers 6 System Registers System Registers System Registers 7 System Registers System Registers System Registers 8 System Registers System Registers System Registers 9 System Registers System Registers System Registers 10 System Registers System Registers System Registers 11 System Registers System Registers System Registers 12 System Registers System Registers System Registers 13 System Registers System Registers System Registers 14 System Registers System Registers System Registers 15 System Registers System Registers System Registers 16 System Registers System Registers System Registers 17 System Registers System Registers System Registers 18 System Registers System Registers System Registers 19 System Registers System Registers System Registers 20 System Registers System Registers System Registers 21 System Registers System Registers System Registers 22 System Registers System Registers System Registers 23 System Registers System Registers System Registers 24 System Registers System Registers System Registers 25 System Registers System Registers System Registers 26 System Registers System Registers System Registers 27 System Registers System Registers System Registers 28 System Registers System Registers System Registers 29 System Registers System Registers System Registers 30 System Registers System Registers System Registers 31 System Registers System Registers System Registers 32 wHold wHold Packet2Storage 33 StatusHold StatusHold Packet2Storage 34 Temp0 SleepCounter_Flags2 Packet2Storage 35 Temp1 RandomNumber2 Packet2Storage 36 BitCounter TimeAfterComms Packet2Storage 37 ByteCounter RAMDump Packet2Storage 38 ByteCounterCopy RAMDump Packet2Storage 39 RandomNumber RAMDump Packet2Storage 40 TimeOut RAMDump Packet2Storage 41 ReturnedByte, Temp3 RAMDump Packet2Storage 42 ReturnFromPFP RAMDump Packet2Storage 43 Flags RAMDump Packet2Storage 44 I2CControlByte RAMDump Packet2Storage 45 DataLengthL RAMDump Packet2Storage 46 DataLengthH RAMDump Packet2Storage 47 PreAmble1 RAMDump Packet2Storage 48 PreAmble2 RAMDump Packet2Storage 49 PreAmble3 RAMDump Packet2Storage 50 STX0 RAMDump Packet2Storage 51 STX1 RAMDump Packet2Storage 52 LoggerType RAMDump Packet2Storage 53 SerialNumber0 RAMDump Packet2Storage 54 SerialNumber1 RAMDump Packet2Storage 55 SerialNumber2 RAMDump Packet2Storage 56 SerialNumber3 RAMDump Packet2Storage 57 PreAmb1, PacketType RAMDump Packet2Storage 58 OutGoingPacketData RAMDump Packet2Storage 59 OutGoingPacketData RAMDump Packet2Storage 60 OutGoingPacketData SecurityCode0 Packet2Storage 61 OutGoingPacketData SecurityCode1 Packet2Storage 62 OutGoingPacketData SecurityCode2 Packet2Storage 63 OutGoingPacketData SecurityCode3 Packet2Storage 64 OutGoingPacketData, IncomingPacketData IncomingPacketData, Packet1Storage Packet2Storage 65 OutGoingPacketData, IncomingPacketData IncomingPacketData, Packet1Storage Packet2Storage 66 OutGoingPacketData, IncomingPacketData IncomingPacketData, Packet1Storage Packet2Storage 67 OutGoingPacketData, IncomingPacketData IncomingPacketData, Packet1Storage Packet2Storage 68 OutGoingPacketData, IncomingPacketData IncomingPacketData, Packet1Storage Packet2Storage 69 OutGoingPacketData, IncomingPacketData IncomingPacketData, Packet1Storage Packet2Storage 70 OutGoingPacketData, IncomingPacketData IncomingPacketData, Packet1Storage Packet2Storage 71 OutGoingPacketData, IncomingPacketData IncomingPacketData, Packet1Storage Packet2Storage 72 OutGoingPacketData, IncomingPacketData IncomingPacketData, Packet1Storage Packet2Storage
24 73 OutGoingPacketData, IncomingPacketData Packet1Storage Packet2Storage 74 OutGoingPacketData, IncomingPacketData Packet1Storage Packet2Storage 75 OutGoingPacketData, IncomingPacketData Packet1Storage Packet2Storage 76 OutGoingPacketData, IncomingPacketData Packet1Storage Packet2Storage 77 OutGoingPacketData, IncomingPacketData Packet1Storage Packet2Storage 78 OutGoingPacketData, IncomingPacketData Packet1Storage Packet2Storage 79 OutGoingPacketData, IncomingPacketData Packet1Storage Packet2Storage 80 OutGoingPacketData, IncomingPacketData Packet1Storage 81 OutGoingPacketData, IncomingPacketData Packet1Storage 82 OutGoingPacketData, IncomingPacketData Packet1Storage 83 OutGoingPacketData, IncomingPacketData Packet1Storage 84 OutGoingPacketData, IncomingPacketData Packet1Storage 85 OutGoingPacketData, IncomingPacketData Packet1Storage 86 OutGoingPacketData, IncomingPacketData Packet1Storage 87 OutGoingPacketData, IncomingPacketData Packet1Storage 88 OutGoingPacketData, IncomingPacketData Packet1Storage 89 OutGoingPacketData, IncomingPacketData Packet1Storage 90 OutGoingPacketData, IncomingPacketData Packet1Storage 91 OutGoingPacketData, IncomingPacketData Packet1Storage 92 OutGoingPacketData, IncomingPacketData Packet1Storage 93 OutGoingPacketData, IncomingPacketData Packet1Storage 94 OutGoingPacketData, IncomingPacketData Packet1Storage 95 OutGoingPacketData, IncomingPacketData Packet1Storage 96 OutGoingPacketData, IncomingPacketData Packet1Storage 97 OutGoingPacketData, IncomingPacketData Packet1Storage 98 OutGoingPacketData, IncomingPacketData Packet1Storage 99 OutGoingPacketData, IncomingPacketData Packet1Storage 100 OutGoingPacketData, IncomingPacketData Packet1Storage 101 OutGoingPacketData, IncomingPacketData Packet1Storage 102 OutGoingPacketData, IncomingPacketData Packet1Storage 103 OutGoingPacketData, IncomingPacketData Packet1Storage 104 OutGoingPacketData, IncomingPacketData Packet1Storage 105 OutGoingPacketData, IncomingPacketData Packet1Storage 106 OutGoingPacketData, IncomingPacketData Packet1Storage 107 OutGoingPacketData, IncomingPacketData Packet1Storage 108 OutGoingPacketData, IncomingPacketData Packet1Storage 109 OutGoingPacketData, IncomingPacketData Packet1Storage 110 OutGoingPacketData, IncomingPacketData Packet1Storage 111 OutGoingPacketData, IncomingPacketData Packet1Storage 112 OutGoingPacketData 113 OutGoingPacketData 114 OutGoingPacketData 115 OutGoingPacketData 116 OutGoingPacketData 117 OutGoingPacketData 118 OutGoingPacketData, TempLength 119 OutGoingPacketData, TempLength2 120 OutGoingPacketData, TempPointer 121 OutGoingPacketData, TempAddL 122 OutGoingPacketData, TempAddH 123 OutGoingPacketData 124 OutGoingPacketData 125 OutGoingPacketData 126 FCS0 127 FCS1 5.1 Constants Name Value Description STX (logger to REDi) "lg" = 0x6C, 0x67 Start character used in all packets sent by the logger. STX (REDi to logger) "re" = 0x72, 0x65 Start character used in all packets sent by the Master (REDi). Type (Wireless Mini) 0x01 This number plus the loggers serial number for its unique address.

Navigation menu