qwerty elektronik ab

We developed the single bidirectional channel NMEA/Ethernet device N1E a few years ago.

However, its 8-channel sibling, the CN8E quickly took over the market and we have delivered this in considerable numbers, both as a generic product and re-branded for OEM customers.

One everlasting problem with all interface units is that customers never really get satisfied. If we do a unit with two output channels, customers will ask for three or four, and if we design a unit with one set-up jumper there will be a request for more jumpers.

One obvious limitation with our design form factor is room for connection terminals, since there is an obvious dimensional  limitation on the number of possible cable connections!

So we focused on the CN8E and found limited use for the small N1E. However, we have learned that is some installations, the N1E is a simple method to accomplish an extra output in a very flexible manner.

We have now upgraded the software of the N1E to a similar user interface as the CN8E and we are ready to run production batches as required.

It seems, in view of the ongoing ECDIS installation boom, that lack of a lot of very basic NMEA knowledge is causing severe problems.

First of all, all type-approved bridge equipment serial data inputs are compliant with either NMEA 0183/IEC 61162-1, or, especially AIS/Gyro/autopilot equipment which need high speed 38 400 b/s data, NMEA 0183HS/IEC 61162-2.

Both of these standards, where the high-speed version is also compliant with the standard version, are always always galvanically isolated from any other part of the equipment. This makes it possible to safely connect any NMEA data output to one or more inputs in parallell without causing any interference or malfunction.

A couple of years ago, we got aware of the fact that a lot of bridge installations actually were connecting equipment with standard RS232 COM ports (Rx, Tx, GND) to NMEA networks. This is obviously not allowed on a SOLAS ship and violates any type approval. Not only violating the rulework, it is also bad engineering/installation practice, which can result in loss of data, affect other equipment and cause damage.

As a result of this, we did upgrade the 1N4 buffer to the “B” version. This version got a completely new output stage driver, also galvanically isolated not only from the input but also from the power supply. This makes it possible to maintain serial data integrity even if one of the outputs of the unit is connected to a RS232 input. BUT ONLY ONE!

What we see happening now is that a lot of ECDIS installations where sensors are connected to a second back-up ECDIS is causing various problems and malfunctions. The main problem is probably that as the second ECDIS is connected, the uncompliance with the rulework is no longer formal but a real problem!

Apart from the obvious advice to use only strictly type-approved  ports, here is some advice:

DO

• If it is necessary to connect to a RS232/COM/DSub-9 input, this should work to connect  NMEA out A – RS232 Rx and NMEA out B – RS232 GND. It violates a number of rules, but will work with plenty of margin. But again – ONLY ONE! Remaining outputs can feed tyep-approved isolated inputs without problems.
• Use a separate 1N4B unit for each RS232 input to comply with the paragraph above.
• If it in necessary to feed more than one RS232 inputs, it gets trickier. Our advice would be to still connect NMEA out A – RS232 Rx but instead connect NMEA out C – RS232 GND. This would violate the same rules, but would still work, however with less margin!

DO NOT:

• Connect NMEA out B to side-grounded ports (like RS232) unless you know how it is connected.

BEWARE:

• ECDIS and other battery backed-up systems have large 12 or 24 V battery banks, meaning that also small potential differences can cause large currents. We have come across 1N4B units were the parallell PCB path between the NMEA C connections was just vapourized. This could obviously cause problems more severe than loss of data!

Edited and clarified 2013-03-12:

Through the years we’ve had a number of questions around this and we had another discussion yesterday with a customer.

Essentially, a gyro is a device for sensing heading. Some gyros also have a rate output function included. As an extra benefit, we did include a optional rate output setting on our gyro converter.

However, a word of caution is needed. A gyro is a sensor, and as all sensors, this has some limitations. Rate of turn is actually a derivative of the heading and in spite of all good efforts, derivating a signal that in itself has some glitches and inconsistencies will enlarge these.

While it in most cases gives good enough performance on a well-kept high quality gyro synchro signal, the opposite can happen if there is some friction or “hang-ups” in the gyro, especially on a stepper type of gyro. It is fairly obvious that for each reading in a stepper gyro, there are only two possibilities, either the gyro has turned since the last reading, which will produce a rate-of-turn value, or it has not turn to the next step, which will set the rate to zero. This means that there may be a tendency for large variations in the reading of the turn rate. Most stepper gyros are geared to 180:1, which means that each step is 1/3 degree. Rate is calculated each second, so if there has been a single step during this second, this corresponds to 1/3 degree/second or 1/3 x 60 degrees/minute = 20 degrees/minute,

This means that the minimum reading of Rate-of-turn for a 180:1 stepper is 0.0 or 20.o degrees/minute and there is little we can do about it.

We have discussed to implement some kind of filtering to smooth this out, but this is to some extent against the whole idea with the rate indicator, which is to give the crew earliest possible indications of the movement tendency of the ship. Looking at it from theoretical point of view, it is not very clever to derivate a signal and then integrate it to smooth the reading.

So, as a conclusion, if the ROT function is good enough, then we are happy we could help, otherwise, don’t use it!

It should also be emphasized that this DOES NOT replace a rate gyro, which is a IMO mandatory carriage requirement device in some ships. Even if it is possible to set the output message to $TIROT it is still not generated by a rate gyro, but from a heading gyro, which is NOT designed to display rate of turn.

Setting the NMEA ROT signal is described on page 8 in the manual, menu item 3.3. It should be noted that the default setting of this for stepper gyros is Off and it should be clear anyone why this is so. We would prepared to discuss sig al processing solutions, although there is very little we can do about the physics behind it.

The CN8E manual was recently updated and the new version is available in the CN8E page. We are now delivering this unit in different OEM versions although we are struggling to avoid having different firmware versions to maintain.

NMEA issued a press release during the summer about its plans for Ethernet-based “Onenet” and we are just starting to get questions about the relation between this and the IEC 61162-450. It would seem logical that NMEA Onenet and IEC 61162-450 would be related in much the same way as NMEA 0183 and IEC 61162-1, but this is not the case.

The -450 is almost only about transportation of NMEA 0183/IEC 61162-1/-2 massages on the network, while Onenet is very much focussed on the same but for NMEA 2000/IEC 61162-3 PGN’s, which is a very different scope.

However, the CN8E is equipped with a CAN port, which hardware-wise is compatible with NMEA 2000/IEC 61162-3 as well as SAE J1939 and various other CAN-based systems.

But the unit does NOT decode or interpret the 2000 PGN’s in any way, it merely packages and transports the CAN frames. This means that they can be handled and decoded by any device receiving the UDP’s generated by the CN8E.

As members of IEC TC80 WG6 we will monitor what is going on with NMEA Onenet, which still has some way to go before publication and we will certainly be susceptible to any requirements from our customers.

The marine industry lives in its own cycles and it is not always easy to predict where the market is moving. A rather high interest for the CN8E NMEA/CAN/Etthernet LWE interface was expected, but that the worldwide ECDIS and system installation activities also required other interfaces to such a large extent caught us slightly off guard.

But we are now well stocked and have ongoing production/testing/calibration acitivities to keep a healthy flow.

We would like to wish all our customers, new and old, a Merry Christmas and a Happy New Year!

We will NOT close for holidays or anything like that, but there is a tendency that the global transport infra-structure take some strain this time of the year! December 25 and 26 are holidays in Sweden and the remaining weekdays are called “squeeze-days” and we think you can imagine why!

Especially, where we are located, in Eastern Sweden, we are now 100 % sure to have a white Christmas, we have snow up to a point that we are expecting transportation problems. Just went behind the office and took this snapshot.

It took us some longer than expected, but all units an orders and back-orders should be dispatched before Christmas.

We have units in stock, but we have already placed an order for another production batch which should secure delivery also early next year.

Predicting the market is among the harder things to get right. As we all know, much of what happens is controlled by IMO carriage requierements.

We were able to place ourselves fairly well for  “AIS gold rush” a few years ago with the gyro converter S2N and some other interfaces. The S-VDR also created some interface needs and there is some activity around the ECDIS and also the BNWAS. Dispite that these are known facts, the order intake towards the end of the summer anyhow took us a bit of guard, more or less depleting our stock.

After some intense work, we are now in a better position to serve customers with our products:

CN8E. This is a typical OEM product by its very nature, being part of other player’s integrated systems. We have a healthy stock and we are now shipping units with SW version 99061-0.1.18 with a number of changes:
– Default ip corrected to 172.16.0.2, rather than 176…
– New test/demo software for UDP communication qeth.py, now a Python 2 script, possible to run on almost any conceivable platform.
– Further enhanced CAN settings.

1N4B. This unit is constantly beating its way to the ships, in most cases via service engineers. The constant increase of the complexity of the bridge equipment means that the load of existing NMEA channels gets higher and the 1N4B creates some valuable extra margin.

We have been very close to empty store for this unit, but we are now well stocked.

S2N. This unit was designed primarily to be a all-singing, all-dancing mother of all gyro interfaces. Since a couple of years, the market for this has been mature, where many of these are finding their ways to installations where the unit’s ability to produce 50 Hz update rate maintaining 0.1 degree inaccuracy also for navy-style 1:1 synchro outputs.

We are at the moment completely out of stock, but we will be re-stocked within a few weeks. The new production batch will have skightly larger cable glands (as a response to customer requirenents) and an updated SW 99002-0.6.5, where we have removed the possibility for SW upgrade via the NMEA port (a feature that hasn’t been used for a number of years).

We have noticed that the number of received telefacsimile messages are now very few and it is time for us to shut down the fax service we are subscribing to.

Our octal NMEA/CAN/Ethernet interface is becoming an important building-block for various navigation elektronics project.

We are now releasing software version 99061_0_1_16 for this unit, featuring a number of new functions:

• Inclusion of -450 header
• Support for -450 four digit instance number
• CAN bit rate setting to cope also with non-NMEA 2000 industrial CAN bus systems
• Extensive CAN filtering
• Improved NMEA, CAN and Network monitoring

It is obvious that typical systems using a CN8E unit in most cases are OEM products that requires close co-operation with our customers. This means that the focus is on software development, testing and mutual cooperation rather than just delivering boards!

To ease this, se have developed a new test utility, called “qeth”. In contrast to the previous Windows-based utility wn8e.exe, the new utility is written in Python, meaning that it should be possible to use on any platform, Linux, Windows, Mac OS or virtually anything invented.

Compared to wn8e, the data throughput is dramatically increased and the possible test data generation has been tailored to the new functionality

We are also making the source-code for this utility available to our customers.

We are currently working hard with new versions of the manual as well as modifying our website to reflect the added functionality.

We have a rather large number of units in prototype/test installations with various customers. We would be happy to aid in upgrading these to the new sw version. Please drop us a line and we would sort out if the simplest solution would be that we take the unit to us for upgrade or if we can find a better solution. In principle, new software can be downloaded through a TTL level serial port and a programming utility like Flash Magic.

Please stay tuned for more information and links!