Home

Please email comments@theFlagProtocol.com if you would like to contribute to these issues.

Date Author Comment
04/07/01 nigel@pilotsystems.com Well there are a number of ways. Firstly you could use the R3 command instead of R1, which requests each packet in a block with a single <ACK>. Or then you can make sure that you are using 20ms turn-around.
04/07/01 nigel@pilotsystems.com Yes, we spoke on the phone, and did some more tests.  The 20ms delay is between receiving data from the meter and transmitting the next string. This delay is a deliberate delay (Receive Delay) to allow the meter to go into receive mode after transmitting data. Attempts were made to reduce this, but the resolution of the timers in DOS (and Windows actually) only allow for 18 ticks per sec granularity (ie 56ms).

So we need for a delay, controlled more accurately than the clock that DOS provides. This could be done by a simple delay loop, which would vary on each HHU. A sample timing could be taken (with interrupts disabled) on the hosts o/s when the program is first run. This would allow a more accurate minimum delay time to be established.

02/05/01 bamini@nri.ac.i I am AMR project manager in NRI( www.nri.ac.ir ) . We have developed a pilot radio base meter reading system. In that system we used IEC1107 protocol between primary and secondry devices. We need verify our developed protocol. Please Send for me details (details sent)
24/04/01 ajoy@modnova.com We are developing a range of AMR products encompassing GSM, PLCC and RF in local loop as well as multiplexers. The meters we are in the process of communicating with for data retreival are :
1. ABB Alpha series.
2. Schlumburger - Vectra / Victory.
3. Various local makes. The names of which you may probably not be aware of. Essentially most of these makes claim to be compliant to IEC 61107.

Response: yes with IEC61107 you need to be more specific. Actually FLAG is a sub-set of 61107 and is a much tighter document.

26/02/01 James.Gibson@pri.co.uk Enquiry re Chirps reading for PRI Sprint meter.

Response: The best way to be Chirps compatible is to implement the FLAG protocol (attached FLAG protocol).

23/01/01 David.Widdup@strategicinformation.co.uk Just a general question really. Our company are involved in the AMR field and are presently working on solutions. We are very keen to find companies specialising in the mfg & design of dataloggers that actually use the IEC1107 (Flag) protocol. Basically we require a datalogger that can count pulses and then provide that pulse count over an IEC1107 link to a processor unit
24/11/00 pavel.jamnik@iskraemeco.si I would like to discuse CHIRPS compatibility for our meter MT800 - application for customer where we won a tender. It has protocol   IEC1107/Cmode. How we test the compatibility?
9/10/00 shelleyc@felixstowe.rms.slb.com Nigel, I agree with your summary below, basically I don't think the host can reject the 20ms request since it was assumed that this was a limitation of the meter rather than the host.
6/10/00 Nigel@pilotsystems.com So presumably in theory it is only the meter's capability that is being confirmed, not the PC/HHU. ie the meter is saying " I could accept another message 20ms after I've sent my previous message". I suspect manufacturers have assumed that if the meter can do 20ms turn-around, so can the PC/HHU because it is likely to be more powerful. But since I know that for example IEC Israel are still using Telxon 286s, that is not the case.

Nothing exists to reject the time-out capability indicator. But we could suggest something. But it would be incompatible with the existing installed
meter base. You can update PC/HHU systems, but not meters so easily !


Actually it need not be a problem to the meter manufacturer unless you are supplying hand-held units as well. Usually the problem we have had is in the baud-rate change, reseting the UART at a
different rate takes a bit of time it seems. We've usually got round it by writing a specific comms driver for the particular UART in the machine.

One solution could for the meter to wait till after the baud rate change has taken place before switching to 20ms, ie the first data message (after the P0 seed). I'm willing to bet that is where the problem almost always is.

6/10/00 steve.day@siemens.co.uk
The 20ms response time feature is specified by the tariff device during signon by it sending the 3rd character of it's manufacturer id in lowercase.
This is during the 300 baud section of the protocol. The minimum response time upto the change to higher baudrate is still 200 ms.

After the ACK V Z Y Cr Lf has been sent to the tariff device, the minimum response time of the tariff device is set to 20 ms for the remainder of the communication session.

4/10/00 richard.p.rogers@gb.abb.com We are currently developing a new electronic electricity meter which will talk FLAG. I came up with a question related to the logon phase of a FLAG communication session that stumped even Tim. He suggested I contact you.

If the meter offers up the faster turn-around time of 20ms vs. 200ms (signaled by 3rd character of manufacturer ID being lower case), is there a
mechanism by which the PC/HHU can decline this and maintain the 200ms turn-around time? Both the FLAG and IEC 1107 specifications are a bit vague
on this point.

Any help you can provide will be greatly appreciated.
16/08/00 sfarshi@nri.ac.ir

 

As I have mentioned in my letter, we in Niroo Research Institute are engaged in AMR activities and intend to verify remote meter reading protocols implemented in Iran. I would be grateful if you could send me details (details sent)
09/08/00 OsmanE@beko.com.tr We are mainly interested in manufacturing electronic cards that can be retrofitted in electromechanical meters or complete digital meters. We are also interested in automated reading and billing services as well. We do not want to design neither meters nor communication medium. Drive-by or fixed radio networks are best suitable for collecting data. Could you please send us a presentation that summarizes  development and standardization (FLAG), or schematic designing for the adoption of the communication tools to an ordinary meter as well?
(details sent)