qwerty elektronik ab

It seems like the electronics industry will always suffer from enormous fluctuations in demand. The automotive industry is suffering really bad, with large semiconductor manufacturers stating delivery time of more than one year.

We are small players in this market and it is usually possible to procure 100 CPU’s in the “spot market” (at higher prices, though), but this time it is extremey difficult.

We are working on the problem, currently we can deliver all active products from stock, with one exception, the CN8E.

Our operations are little affected by the current situation. We are relying on subcontractors for PCB manufacturing, testing and logistics, but we have no activity in central Stockholm and as far as we know all shipping operators like UPS, DHL etc offers normal or at least next to normal service, sometimes with a bit slower transportation

Please take care out there!

As many ship installations gets new GPS/Glonass/Galileo receivers, many with enhanced position inaccuracy (= added decimal places), it has been a problem that NMEA messages sometimes gets longer than strictly allowed.

Our firmware was deisgned to check for NMEA syntax errors and discard messages not fulfilling all requirements, but this problem tended to create so much problems so we agreed, in collaboration with our customers, to modify the firmware of the CN8E to allow for NMEA messages having a payload of 140 characters.

However, please note that this is a violation to NMEA 0183 and IEC 61162-1 syntax and may possibly cause message interpretation problems in other connected equipment.

We recenbtly got a question on the Q&A page asking us to clarify the if our products were wheelmarked and type approved.

We have been discussing this, but clarifying this once again makes no harm.

“Short answer is no and yes. But a good explanation takes a few more lines. Units we market, like “something to NMEA converter” (A8N, L1N etc) or NMEA/Ethernet interface (CN8E) cannot be wheelmarked on their own. The reason is simply because these devices are not listed in the MED and as a consequence cannot be wheelmarked on their own.

We have a long experience from type testing and various type approvals since long before the MED came inte force and we are convinced that is necessary for our customers to take care of this.

To solve this, we have done third party environmental testing to IEC 60945, like EMC (expensive!), temperature/climate, vibration, CSD etc and we will make test reports available as required. In addition to this, we will issue necessary certificates of compliance for things like Mould growth or Corrosion resistance. In some cases we also have old-fasioned national type approvals (“Baumusterprüfbescheinigungs“). Our intention is to make it a simple routine task to make our interfaces appear in various system supplier’s certification.

So although we have to answer no to the first question, we have gone as far as possible to give the best possible support to our customers.

Since we are based in Sweden, possible home country of Santa (although our eastern neighbours are convinced he is based in Rovaniemi!) it would be nice to post a snowy picture.

However, the sad  truth is that in the Stockholm area, Christmas time is in most cases more wet green/brown than icy white. Also this time, althogh we had some snow a couple of weeks ago:

Please have a Nerry Christmas and a Happy New Year!

During the time 14 – 24 July, we will have limited capacity and our logistics partner for delivery etc will also mean low activity, “Nordic style”!

Mails will be read on daily basis.

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.