I need short description on the macros to be defined in gxignore.h. Based on this i'll use the required macros only in my client example. Any document supporting this would be helpful.
What is the minimum memory requirement for the microcontroller for client example to run if i use the High authentication(US association)?
Un-comment lines that you don't need. It will remove unused COSEM objects and uses less memory. I can't say anything sure, because I don't know what objects you want to read. Profile generics are usually causing problems if you don't have a lot of memory. You can ignore this if you can read historical data row by row.
Thanks for the reply. I just want to perform the Disconnect and reconnect operation on Relay which is there in the meter.
Some how I'm able to send the SNRF and AARQ frames, But meter is not responding. I tried port sniffer for the GuruX DLMS director, the frames are different and i dont see SNRF or AARQ frames. Please let me know what can be done at my side.
If you are not receiving reply to SNRM, then you need to check the client and server address. They are different compete with GXDLMSDirector. If they are wrong, meter doesn't reply.
GXDLMSDirector client address is 48 0x30 and server address is 16640 0x4100
Server address was wrongly communicated from the meter supplier. With the above server address i'm able to get the response in UART interrupt mode but not by polling api which is
int com_readSerialPort(
connection *connection,
unsigned char eop)
{
//Read reply data.
int pos;
unsigned char eopFound = 0;
unsigned short lastReadIndex = 0;
do
{
io_read(connection->io, connection->data.data, 1);
connection->data.size += 1;
//Search eop.
if (connection->data.size > 5)
{
//Some optical strobes can return extra bytes.
for (pos = connection->data.size - 1; pos != lastReadIndex; --pos)
{
if (connection->data.data[pos] == eop)
{
eopFound = 1;
break;
}
}
lastReadIndex = pos;
}
} while (eopFound == 0);
return DLMS_ERROR_CODE_OK;
}
---Actual io_read implementation as per Example for Atmel
static int32_t usart_sync_read(struct io_descriptor *const io_descr, uint8_t *const buf, const uint16_t length)
{
uint32_t offset = 0;
struct usart_sync_descriptor *descr = CONTAINER_OF(io_descr, struct usart_sync_descriptor, io);
ASSERT(io_descr && buf && length);
do {
while (!_usart_sync_is_byte_received(&descr->device))
;
buf[offset] = _usart_sync_read_byte(&descr->device);
} while (++offset < length);
return (int32_t)offset;
}
In the above code i see the function io_read(connection->io, connection->data.data, 1); receives 1 byte to the same location every time. So finally i end up receiving 1 byte even though meter sent more number of bytes and connection->data.size increments which is clear to me. Please let me know if my understanding is wrong.
Hello Mikko,
I'm able to receive data now using UART blocking mode. But com_initializeConnection() function is returning 271 code which means DLMS_ERROR_CODE_INVALID_TAG not sure why i'm receiving this.
Here is the trace.
TX:7E A0 0A 00 02 04 01 61 93 11 F3 7E
7E A0 23 61 00 02 04 01 73 C5 B4 81 80 14 05 02 00 FA 06 02 00 FA 07 04 00 00 00 01 08 04 00 00 00 01 1C 5A 7E
TX:7E A0 6E 00 02 04 01 61 10 71 8E E6 E6 00 60 5D A1 09 06 07 60 85 74 05 08 01 03 A6 0A 04 08 3E 70 00 91 11 00 00 00 8A 02 07 80 8B 07 60 85 74 05 08 02 02 AC 12 80 10 70 38 9C CE 67 B3 59 AC 56 AB 55 2A 15 8A 45 22 BE 23 04 21 21 1F 30 00 00 00 00 B4 5C 66 20 E5 C8 D7 EC E0 C7 33 73 DB 86 94 87 1B 4B 97 DD 07 EB 72 CD 60 E5 D6 9E 7E
7E A0 12 61 00 02 04 01 30 C5 8D E6 E7 00 D8 01 05 18 05 7E
TX:7E A0 2F 00 02 04 01 61 32 B2 D4 E6 E6 00 C8 1E 30 00 00 00 01 72 E4 F0 72 00 6D 78 C2 86 16 78 53 BC 96 C4 01 F9 EE 45 78 57 C0 C4 2C 08 C3 17 7E
7E A0 12 61 00 02 04 01 52 D1 CD E6 E7 00 D8 01 05 18 05 7E
TX:7E A0 0A 00 02 04 01 61 53 1D 35 7E
7E A0 23 61 00 02 04 01 73 C5 B4 81 80 14 05 02 00 FA 06 02 00 FA 07 04 00 00 00 01 08 04 00 00 00 01 1C 5A 7E
Is there a document other than green book to decode these frames ?
Hi Manju,
Hi Manju,
Un-comment lines that you don't need. It will remove unused COSEM objects and uses less memory. I can't say anything sure, because I don't know what objects you want to read. Profile generics are usually causing problems if you don't have a lot of memory. You can ignore this if you can read historical data row by row.
BR,
Mikko
Hello Mikko,
Hello Mikko,
Thanks for the reply. I just want to perform the Disconnect and reconnect operation on Relay which is there in the meter.
Some how I'm able to send the SNRF and AARQ frames, But meter is not responding. I tried port sniffer for the GuruX DLMS director, the frames are different and i dont see SNRF or AARQ frames. Please let me know what can be done at my side.
Attachment : Frames
Hi Manju,
Hi Manju,
Please, paste text, not images. I can't compare the bytes from the images.
BR,
Mikko
Hello Mikko,
Hello Mikko,
Here is the data as i couldn't upload text files.
From GuruX Library
SNRF:
7E A0 08 04 01 61 93 C2 DF 7E
AARQ
7E A0 6C 04 01 61 10 F2 E5 E6 E6 00 60 5D A1 09 06 07 60 85 74 05 08 01 03 A6 0A 04 08 5A 45 4E 4D 45 54 45 52 8A 02 07 80
8B 07 60 85 74 05 08 02 02 AC 12 80 10 70 38 9C CE 67 B3 59 AC 56 AB 55 2A 15 8A 45 22 BE 23 04 21 21 1F 30 00 00 00 00 0B
D3 DE D1 D6 74 52 D1 13 85 A2 D1 9E 8F A3 E9 5D D9 70 D3 A1 B2 2A 31 1B E4 98 23 7E
From GuruX DLMS Director
000202: 2020-07-28 20:28:53.5595913 +1.0099290
7E A0 21 00 02 04 01 61 93 10 E6 81 80 12 05 01 ~ !....a“.æ€...
FA 06 01 FA 07 04 00 00 00 01 08 04 00 00 00 01 ú..ú............
3E A9 7E
7E A0 6E 00 02 04 01 61 10 71 8E E6 E6 00 60 5D A1 09 06 07 60 85 74 05 08 01 03 A6 0A 04 08 5A
45 4E 6D 65 74 65 72 8A 02 07 80 8B 07 60 85 74
05 08 02 02 AC 12 80 10 6F 51 07 4A 5C 29 27 58
49 6D 40 4A 45 3D 1C 01 BE 23 04 21 21 1F 30 00
00 02 58 D2 57 74 CB 4B 60 2E 5F 77 D1 3A 33 A0
0B 0E 90 E7 44 2C 0B CB AB 94 88 8D ED 6D 15 7E
000350: 2020-07-28 20:28:54.0807277 +0.0020889
7E A0 41 00 02 04 01 61 32 16 F6 E6 E6 00 CB 30 ~ A....a2.öææ.Ë0
30 00 00 02 5B DB CF CC 95 B9 F8 99 08 9A 5F 8B 0...[ÛÏÌ•¹ø™.š_‹
8E 40 69 99 A9 FC 01 2B A2 D4 A2 78 D7 46 2A 7C Ž@i™©ü.+¢Ô¢x×F*|
18 11 D8 F9 4D C6 FD 6D 14 8F E4 1B 25 BA 27 A1 ..ØùMÆým.ä.%º'¡
9F E3 7E Ÿã~
000400: 2020-07-28 20:29:59.0719708 +64.7692484
7E A0 31 00 02 04 01 61 54 6A E1 E6 E6 00 CB 20
30 00 00 02 5C C8 BE D7 FC 1A C2 18 51 D3 1C B7
1F 65 A1 09 0E 64 B7 06 77 93 D3 B6 DA 4C 74 6E
7F 7E
000438: 2020-07-28 20:30:16.9901501 +16.7043065
7E A0 31 00 02 04 01 61 76 7A E3 E6 E6 00 CB 20 ~ 1....avzãææ.Ë
30 00 00 02 5D FF 20 0A 5C 09 B4 81 A3 EF 51 FC 0...]ÿ .\.´£ïQü
5F 00 D6 AA 0D DC 6E F5 DD E3 02 D4 54 0A 73 C2 _.Öª.ÜnõÝã.ÔT.sÂ
47 C3 7E GÃ~
000476: 2020-07-28 20:30:26.2448106 +8.0322696
7E A0 14 00 02 04 01 61 98 2A 7E
000580: 2020-07-28 20:30:46.7144907 +5.0168577
7E A0 0A 00 02 04 01 61 53 1D 35 7E
Note : Duplicate frames are removed
Hi,
Hi,
I believe that you are reading Invocation Counter in GXDLMSDirector. You need to read it before you make a ciphered connection with ANSI C.
BR,
Mikko
Hello,
Hello,
is there any api to get the invocation counter?
Atleast i should get the reply for SNRF frame right?
Hi,
Hi,
If you are not receiving reply to SNRM, then you need to check the client and server address. They are different compete with GXDLMSDirector. If they are wrong, meter doesn't reply.
GXDLMSDirector client address is 48 0x30 and server address is 16640 0x4100
BR,
Mikko
BR,
Mikko
Hello Mikko,
Hello Mikko,
Server address was wrongly communicated from the meter supplier. With the above server address i'm able to get the response in UART interrupt mode but not by polling api which is
int com_readSerialPort(
connection *connection,
unsigned char eop)
{
//Read reply data.
int pos;
unsigned char eopFound = 0;
unsigned short lastReadIndex = 0;
do
{
io_read(connection->io, connection->data.data, 1);
connection->data.size += 1;
//Search eop.
if (connection->data.size > 5)
{
//Some optical strobes can return extra bytes.
for (pos = connection->data.size - 1; pos != lastReadIndex; --pos)
{
if (connection->data.data[pos] == eop)
{
eopFound = 1;
break;
}
}
lastReadIndex = pos;
}
} while (eopFound == 0);
return DLMS_ERROR_CODE_OK;
}
---Actual io_read implementation as per Example for Atmel
static int32_t usart_sync_read(struct io_descriptor *const io_descr, uint8_t *const buf, const uint16_t length)
{
uint32_t offset = 0;
struct usart_sync_descriptor *descr = CONTAINER_OF(io_descr, struct usart_sync_descriptor, io);
ASSERT(io_descr && buf && length);
do {
while (!_usart_sync_is_byte_received(&descr->device))
;
buf[offset] = _usart_sync_read_byte(&descr->device);
} while (++offset < length);
return (int32_t)offset;
}
In the above code i see the function io_read(connection->io, connection->data.data, 1); receives 1 byte to the same location every time. So finally i end up receiving 1 byte even though meter sent more number of bytes and connection->data.size increments which is clear to me. Please let me know if my understanding is wrong.
Hi,
Hi,
You must check how many bytes you are receiving from UART in io_read. If you are not using blocking mode, read byte size might be zero.
Try something like:
if (io_read(connection->io, connection->data.data + connection->data.size, 1) == 1)
{
connection->data.size += 1;
//Search eop.
if (connection->data.size > 5)
...
}
Hello Mikko,
Hello Mikko,
I'm able to receive data now using UART blocking mode. But com_initializeConnection() function is returning 271 code which means DLMS_ERROR_CODE_INVALID_TAG not sure why i'm receiving this.
Here is the trace.
TX:7E A0 0A 00 02 04 01 61 93 11 F3 7E
7E A0 23 61 00 02 04 01 73 C5 B4 81 80 14 05 02 00 FA 06 02 00 FA 07 04 00 00 00 01 08 04 00 00 00 01 1C 5A 7E
TX:7E A0 6E 00 02 04 01 61 10 71 8E E6 E6 00 60 5D A1 09 06 07 60 85 74 05 08 01 03 A6 0A 04 08 3E 70 00 91 11 00 00 00 8A 02 07 80 8B 07 60 85 74 05 08 02 02 AC 12 80 10 70 38 9C CE 67 B3 59 AC 56 AB 55 2A 15 8A 45 22 BE 23 04 21 21 1F 30 00 00 00 00 B4 5C 66 20 E5 C8 D7 EC E0 C7 33 73 DB 86 94 87 1B 4B 97 DD 07 EB 72 CD 60 E5 D6 9E 7E
7E A0 12 61 00 02 04 01 30 C5 8D E6 E7 00 D8 01 05 18 05 7E
TX:7E A0 2F 00 02 04 01 61 32 B2 D4 E6 E6 00 C8 1E 30 00 00 00 01 72 E4 F0 72 00 6D 78 C2 86 16 78 53 BC 96 C4 01 F9 EE 45 78 57 C0 C4 2C 08 C3 17 7E
7E A0 12 61 00 02 04 01 52 D1 CD E6 E7 00 D8 01 05 18 05 7E
TX:7E A0 0A 00 02 04 01 61 53 1D 35 7E
7E A0 23 61 00 02 04 01 73 C5 B4 81 80 14 05 02 00 FA 06 02 00 FA 07 04 00 00 00 01 08 04 00 00 00 01 1C 5A 7E
Is there a document other than green book to decode these frames ?
Hi Manju,
Hi Manju,
Encryption fails for some reason. Read the Invocation (frame) counter first. That might be the reason.
BR,
Mikko
Thanks Mikko. But how to read
Thanks Mikko. But how to read the invocation counter?is there any api in the library?
Hi,
Hi,
Find com_updateInvocationCounter method from the client example. It will do what you want.
BR,
Mikko