The protocol IEC 62056:21 tells us how to deal with enegy meters, it's quite easy!

The part where I am stuck is the implementation over a GSM data channel. Normally I would set things like:

• 300 baudrate
• 1 parity bit (even)

But the meter is not connected via serial connection but, instead, it has a sim. Using a modem I can call the meter using:

AT&C1
ATDNumber

Problem 1: Settings

The modem calls the meter with different settings (baudrates, stopbits, parity) compared to the protocol ones, e.g.

• 9600 baudrate for call
• 300 baudrate for first messages
• xxxxx new baudrate shared between master and slave

Can I change these parameters during call?

Problem 2: Send data

After I establish a call, I would send to the meter things like:

/ ? Device address ! CR LF

Here's the missing piece, I don't know how to send this data over the call

I am reading and trying several libraries (like J62056, pyserial), but I've found nothing about sending data via gsm call

EDIT I read a trace of a proprietary software, and I got this:

TX: 140ms AT&C1E0V0 RX: 32ms 0 TX: 1203ms ATDT ##########RX: 34656ms 1RX: 0ms 5RX: 0ms  TX: 3234ms <NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL> *what is this?*TX: 594ms /?########! (this the Request message) **start sending data**

The < NUL > part is not Clear, and this is where the modem starts to send data Edit: I read about the 8 null chars, they're just a check-in sequence.

At the moment, after the modem established the call I translate my 8 bit no parity sequence into a 7 + parity one. Now i am able to send and receive data from the meter, I must test other feature before writing my solution to this answer

Without knowing anything about IEC 62056:21, if your energy meter supports this over GSM circuit switched data (CSD), nothing it says about speed and parity in the normal non-GSM case is relevant at all.

Because the data call you set up will be non-transparent CSD (NTCSD). A transparent call would have treated the gsm connection as much as just an electrical wire as possible (which in best case is difficult¹), forwarding each byte received immediately and with no buffering nor with any retransmission support. A non-transparent connection on the other hand will receive/send its data to an intermediate entity which in turn communicates with the other end point, and will support buffering and retransmission.

For GSM NTCSD, the part of the phone responsible for data handling is called TAE (Terminal Adapter Equipment) or TAF (T. A. function), and the relevant protocol² is called RLP (Radio Link Protocol) which is specified by 3GPP in specification 24.022. It is a link-layer protocol similar to HDLC, and it communicates with a unit in the GSM network called MSC (Message Switching Centre). It is then then MSC which communicates with the other end, on a different and completely separate communication line (which can be PSTN, ISDN or mobile network depending on what kind of device the remote end is).

     mobile modem  <----link1---->  MSC <----link2---->  remote endpoint

The important thing here is that the two links are 100% independent, and they do not have to be the same speed.

Thus whatever speed your energy meter is using over some serial interface between itself and the embedded modem with SIM card is independent of the radio link1 speed which itself is independent of the network link2 speed which your modem will have.

So the above should be an answer to your question, but let me fill in some more information with regards to the speeds of link1 and link2, because this can be controlled with two AT commands AT+CBST and AT+CHSN (specified in 27.007).

The basic GSM data traffic channel is called TCH/9.6 (Traffic Channel), which is a channel with net 9600bit/s speed (seen by the user) and 12000bit/s gross speed (seen by the network). In order to enhance throughput HSCSD (High Speed CSD) was developed which introduced a new channel coding and a new channel TCH/14.4 which had 14500bit/s gross speed and 13200bit/s net speed (which of course all the marketing people presented as 14.4 speed even though that not was really true).

In addition HSCSD allowed for bundling multiple timeslots together (multislot). A frequency band in GSM is divided into 8 timeslots, where an active call occupies one timeslot in the downlink direction and one timeslot in the uplink direction. Thus a cell tower configured to support only one frequency band supports maximum 8 simultaneous calls.

What HSCSD introduced was the possibility to set up a call that could use multiple (adjacent) timeslots, for instance two downlink timeslots and one uplink (denoted 2+1). The different multislot configurations a phone or network supported were categorised in multislot classes³ (with 2+1 being multislot class 10 as far as I remember).

Since HSCSD both was an added value and occupied more network resources this was something that was billed higher than a normal 1+1 9600 call, and thus the users had to have some control over if they used HSCSD or not. This was done by introducing the AT+CHSN command which controls the link1 speed.

Support for hinting to the MSC what speed it should use for link2 was implemented by the AT+CBST command (which already existed before HSCSD). Since the AT command is terminated in the mobile phone, its value had to be forwarded to the MSC in some way, and this was done out-of-band (with regards to the RLP data link) in a Bearer Capability Information Element in some of the call setup messages.

So, that's probably more than you need to know about speeds in a GSM network for a NTCSD call, but having developed and maintained the NTCSD call stack in Ericsson's mobile phones for over a decade, this is something I know quite well...

¹ While there are standardized some support for transparent data, this was more of a legacy thing done in the 90-s in order to support equipment made in the 80-s. Operators do not want to have this supported today because it is a pain in the butt to get working and to support.

Fax over GSM for instance was such a transparent bearer, and it was a massive test everywhere approach with no guarantee that it would work even if you followed the specification fully. You had to do your best effort implementation and then you had to travel all over the world testing it and try to fix all the issues that would pop up (which they absolutely did. And even if the problem was something wrong with the network, the operator might not want to fix it so you had to add some custom workaround).

One of the guys working with fax support told me that in some cases they had to start sending the response before they had gotten the request in order for the timing to work out (e.g. they had to guess and anticipate what the remote fax would do).

It is not without a reason that phones manufactured and operators today do not support fax like they did in the 90-s, early 2000.

² In addition there is L2RCOP which is just a framing adoption between packet based RLP and the physical serial interface.

³ CSD and GPRS both supported multislot, but not necessarily the same class, i.e. CSD multislot class is independent from GPRS multislot class.