Please email comments@theFlagProtocol.com if you would like to contribute to these issues.
|firstname.lastname@example.org||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.|
|email@example.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.
|firstname.lastname@example.org||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)|
|email@example.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
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|
|firstname.lastname@example.org||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?|
|email@example.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 !
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.
|firstname.lastname@example.org||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.
|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?