Chint DTSU666 Modbus RTU - odczyt rejestrów zwraca same zera na ATmega328P

Cześć,
od kilku dni próbuję odczytać dane z licznika energii Chint DTSU666 za pomocą mikrokontrolera ATmega328P i BASCOM-AVR przez protokół Modbus RTU.
Używany sprzęt:

Mikrokontroler: ATmega328P
Komunikacja: RS485 (półdupleks)
Licznik: Chint DTSU666 (adres slave ustawiony na 2)
Wyświetlacz: LCD 20x4 na ekspanderze I2C PCF8574

Opis problemu:
Licznik odpowiada na zapytania Modbus RTU, jednak zawsze zwraca same zera. Niezależnie od tego, jaki rejestr próbuję odczytać (napięcie, prąd, moc, częstotliwość), wartość po złożeniu do zmiennej Single wynosi 0.0.
Co ważne — ten sam efekt występuje również przy użyciu zewnętrznego programu "modbus master". Czyli problem nie dotyczy tylko mojego kodu w BASCOMie.
Przykładowe ramki z programu "modbus master":
Wysłane (TX):
01 03 00 00 00 08 44 0C
Odebrane (RX):
01 03 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E4 59
Licznik odpowiada poprawnie (prawidłowa długość ramki i suma kontrolna), ale wszystkie 8 odczytanych rejestrów zawierają same zera.
Przykładowy kod odczytu w BASCOM-AVR:
Używam standardowej funkcji do odczytu wartości float (2 rejestry holding):
basic

Funkcja Read_float odczytuje dwa kolejne rejestry i składa je do zmiennej typu Single za pomocą instrukcji Poke.
Pytanie:
Dlaczego licznik Chint DTSU666 zwraca same zera przez Modbus RTU?
Czy w tym modelu dane pomiarowe są domyślnie niedostępne i trzeba najpierw ustawić jakieś parametry (np. przekładnie CT/PT)?
Czy może licznik zwraca dane tylko po stronie wtórnej i należy je przemnażać przez ustawione przekładnie?
Będę wdzięczny za wszelkie wskazówki i sugestie.

parametr PROT - ustaw coś innego niż 1 (645 mode) i dostosuj parametry transmisji.

Mam transmisję ustawioną na 8n1 9600 baud, sprawdziłem nawet fizycznie wewnątrz licznika czy sygnały są elektrycznie poprawne, siedzi tam zamiennik max485 i wszystko jest ok.
Ramki były wysyłane gdy licznik miał adres 01, stąd:
Wysłane (TX):
01 03 00 00 00 08 44 0C
Odebrane (RX):
01 03 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E4 59
Niestety po zmianie adresu odbieram to samo(czyli same 0).

pytanie jest poprawne
pytasz o pierwsze 8 rejestrów (holding registers) urządzenia 01

ale odpowiedź już nie - nie zgadza się CRC

https://rapidscada.net/modbus/

Spróbuj odczytać rejestry od 2000H w górę
Spróbuj użyć do odczytu funkcji 04
sprawdź czy przypadkiem nie masz zamienionych linii A z B
Raz jeszcze sprawdź w liczniku parametr PROT

1) prot jest na n.1, a baud na 9600.
2) po zamianie linii A oraz B w ogóle nie odpowiada-bo dlaczego miałoby być inaczej.
3) spod adresu 2000H wywala błąd 83, lecz spod adresu 1000H odczytuje:
TX: [0x02][0x03][0x10][0x00][0x00][0x10][0x40][0xF5]
RX: [0x02][0x03][0x20][0x02][0xBD][0x00][0x68][0x00][0x00][0x00][0x00][0xFF][0xFF][0x00][0x01][0x00][0x0A][0xFF][0xFF][0x00][0x00][0x00][0x03][0x00][0x00][0xFF][0xFF][0x00][0x03][0x00][0x03][0x00][0x02][0xFF][0xFF][0x96][0xDE
4) odczytuje zarówno za pomocą 03h oraz 04h.

zwrócił poprawną ramkę ale ma się to nijak do mapy rejestrów z instrukcji.
opieram się na tym:
https://www.chintglobal.com/content/dam/chint.../manual/DTSU666%20DSSU666%20User%20Manual.pdf

Także zauważyłem rozbieżności pomiędzy instrukcją a licznikiem. Jakieś dalsze pomysły?

Zaczął bym od sprawdzenia (podania) dokładnego typu licznika - może są jakieś wersje różniące się oprogramowaniem.
Następnie poszukiwanie instrukcji.

Samodzielne zgadywanie mapy rejestrów to żmudne zajęcie. Polecam konsolowego modpoll-a - potrafi rozkodowywać float
https://www.modbusdriver.com/modpoll.html