### Last forum posts

- Re: Revision of JANUS STANAG next year in March
- Proposed new Class ID: Secure Pre-Canned Message
- Re: JANUS frequency-band proposal of EDA-SALSA consortium
- Re: JANUS frequency-band proposal of EDA-SALSA consortium
- JANUS frequency-band proposal of EDA-SALSA consortium
- Re: Please generate a EMCON-forum
- Please generate a EMCON-forum
- Publication of an updated version (v0.2) of the JANUS Emergency messages specification proposal
- Announcing the 2019 JANUS Workshop
- Re: Publication of an updated version (v0.2) of the JANUS Underwater AIS message specification proposal

## Re: Revision of JANUS STANAG next year in March

in the NATO standard ANEP-87 - „Digital underwater signalling standard for network node

discovery and interoperability“, appendix B and C two time scaling formulas are being used.

The problem:

1) The values provided in Table in ANNEX B are likely not to be implementable in the hardware to be used in the given accuracy. page V

2) The same for ANNEX C. Here the case is more difficult! The values of the table C-1 are not

fitting to the formula. If you are using 50 digits, the correct basis is not

1.176769793407883 it is

1.176769793407882894...

to generate the values of the table.

If you have the accuracy (only MAPLE, MATHEMATICA, ... - not on a

simple computer) you can calculate the index correctly, otherwise NOT!

Different computers, different time slots!

3) For some/many applications we need not the time, we need the number of bits

in form of a length field.

In Janus we have the situation 2 chips = 1 bit (with the coding). In 2.1.11 2. the Chip

duration is Cd = 0.00625 s. With this we have an interaction between bit and time!

Each index in the table in ANNEX B and C can interpret as time AND length in bit!

like (index N, time = intN? * Cd, length_in_bits = intN?)

With this concept we have a length field without changing the allocation map, can

transmit JANUS cargo also in case of repetitions

Best regards

Ivor

Reads: 421