Here are some notes:

After having looked at the various documentation, the Digital Data (DD) mode
of the 1.2 GHz Icom ID-1 is a rather strange design.
There is reason for concern on that the amount of overhead is huge (D-STAR
header + Ethernet header + IP header), and that the FEC as implemented is a
bit strange (why does it only apply to the D-STAR header, and not the
Ethernet frame?). Further the protocol has no real mention of channel access
concerns (collision detection, avoidance, etc). It really looks to me like
DV with ethernet frames stuffed into the payload section (i.e. maybe it was
somewhat of an afterthought).

All the DD mode appears to do is forward ethernet frames around. On its own,
it does not do any acknowledgement/handshaking. This is all left to the
upper-layer protocols (i.e. TCP).

It appears that if a collision happens then the DD packet is just lost, and
there's no really mechanism to avoid collisions at the DD layer, either.
It's up to the higher-layer protocol to do anything about it.

So you really have no indicator of channel quality when using it. The lack
of this sort of thing seems like a major oversight. It looks like packet
radio done badly, although with better speeds. If it were introduced 15 to
20 years ago we would have hailed it as the savior of packet radio, but now
it looks like a poor imitation of WiFi.

To further, it doesn't help most of what you will read on the other D-Star
Yahoo groups shows that the ID-1 isn't being used with good RF engineering
practice leading to poor results.

Regarding a BER value. You could in theory determine it from the radio
header, decode it, and then re-encode it, and compare the bit patterns. That
way you could get a BER value which for a fixed link would be applicable to
the whole packet. You'd need external homebrew hardware to do this.