qwerty elektronik ab

Manual and labeling has been modified accordingly.

We finally got the expected and promised delivery of the ARM CPU and we have a production batch of the Octal NMEA/CAN/Ethernet interface unit CN8E available and we will start shipping orders from our backlog.

We will approach all customers using E.mail.

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!