Multitech Conduit AP

Well 1stly would recommend you move sensors further from the GW’s! (or move the GW’s away from the sensors). If at just 1m you are pretty well operating in near-field vs far-field mode (typically look to be >>4/6 full wavelengths away) and then precise placement can be an issue. Also at such close range you may well be overloading the front end. I know most GW manufactures recommend running any nodes operating at full power (14dbm ERP in EU, potentially >>20dbm in US and elsewhere) be placed at least 2m away from GW antenna to avoid issues. By saturating its poss LoRa message may ‘appear’ on several channels causing GW demux confusion and lost packets/CRC errors causing NS to drop etc.

Looks like the two styro-foam mounted antena’s route to the Telit Cellular card? (don’t have one to hand to confirm - but orthogonal layout suggests may be the case). Suspect the LoRa antenna is the strip close to the edge of photo opposite the Cellular modem?

Even such a weak antenna (compared to external co-linear, dipole or monopole x-dbi unit will likely capture enough signal to cause issues.

Would suggest realistic test is to place say 5-10m+ away in both instances…

1 Like

…i learnt the distance issue the hard way whilst doing comparative testing of 4 different gateways in my office - with 3 sensors as sources - found every so often one GW (closest to one sensor) would show same packet serial# count but on apparently different channel freq (adjacent channel)…! Solution was another metre of separation… :slight_smile:

Hi Jeff, thanks for the info! Unfortunately, I’m not sure that’s the case… I went and dug through my data and found this from last week:
widget_5aaa5c16f159691290bc2421%20(3)
I only had 3 sensors online then, but this was when I was doing some range testing - All sensors are 10-50 meters from the device.

I’m not seeing any changes :neutral_face:

Ah well in that case at least you will have eliminated one of the poss sources of errors! :slight_smile: :wink:

One step closer! :wink: Also, the first time round, I was comparing it to the Kerlink iFemtocell. This device was located next to my MTCAP, meaning that it was also within 1m of the sensors… and no issues there!

I’ve sent a detailed email to my distributor, it’s likely they’ll provide me with another unit to see if the issues still persist.
Also, as you can see above, I did open the device and look around. I was worried that by doing this I might have broken something, but I checked my data from before I opened the device, and the results are the same.

Yes picked up on the iFemtocell comparison - hence ref to fact that in near field exact placement (and indeed device/ant orientation) may be an issue…reflections, strength of RF em wave etc. also the precise layout and component use in each systems front end as well as any associated housing/layout screening and orientation may impact susceptibility to the problem and any associated none linearity of circuits as they approach saturation etc. tolerances could mean even two units the same from same supplier may behave slightly differently…

…just something to be aware of and always do testing in far-field just in case and far enough away that front end issues dont play a part (note can also dial down test node Tx pwr to help mitigate if close proximity due to working environment means close placement a must)…

Good luck…

Hey @onehorse, you’re the only other person I know who is actively using these units. Have you been experiencing issues like this?

The SSH jumphost idea is an interesting one! I must ask though: what are the advantages of this method, compared to using an OpenVPN server/client model?

I’m not sure how to plot missing packets, but I have been using the MTCAP gateway for months and have never noticed any missing data. But I don’t scrutinize to every last byte. When I do testing and send data every ten seconds I see all the bytes as expected. I haven’t noticed anything missing on Cayenne when I look at the numerical data. So I can’t corroborate Eelviny’s findings, nor can I refute them. But it is working as expected and well enough for my needs. If there are missing packets, it just doesn;t matter for my simple use cases.

Many reasons, all small/practical, but in aggregate compelling.

  • Several of us have been using SSH for connection to corporate mail servers while traveling extensively for 20+ years. I have good feel for whether it’s going to work and what the issues are. I know it will work through most routers, NATs, etc., w/o requiring any reconfiguration.
  • SSH is already present on anybody’s machine.
  • We all already depend on SSH, so it’s a smaller “perimeter” (fewer tools, less knowledge required).
  • We have to be using SSH anyway for Ansible.
  • Using “ssh over vpn” adds a third layer of network transport – I also know from experience that this can be tricky due to path MTU discovery issues.

Hmm… so in this case I’m just kinda hoping that I got a defective unit. I’m still evaluating different models, but even if it is a defective unit, I’d be worried that if I bought a fleet of them, I’d encounter more issues like this and it would be very difficult to solve them.

As for plotting missed packets, I use two methods: first is having messages only sent at set intervals, so I know how many to expect, and also the packet counter - if it increments by more than 1, a packet is missed.

I took the MTCAP and a sensor home for the weekend, as I live in the countryside where there are no other gateways around, so no interference. Here’s my results:
widget_5aaa5c16f159691290bc2421%20(4)
These results are definitely better than when it was in the centre of Amsterdam, but still not acceptable. I restarted the gateway at 14:00 on the 14th, so discount the lowest value there!

Hello! There aren’t a lot of resources online for this particular product so if anyone here could help out a student newbie that would be amazing. I have the non cellular version of this router, and I’ve having the hardest time getting it to connect at all to an SSH connection. For context, the router was provided to my university by Comcast in the last few months, and to our knowledge, no one else has used this router. The end goal is to have two Marvin development boards communicating.

In the user guide on page 19, I’m literally stuck between steps 1 and 2, and it’s quite possible that that instructions given may not be accurate. I’m using Windows 10 and Putty, and after updating the static IP address for iPv4 and trying to connect in Putty, I get the error “connection refused”.

The lights come on, and I’ve reset it several times. I’ve also tried a different computer and Tera Tern instead of Putty. Traffic seems to be going to the router, but packets aren’t coming back. I’ve pinged both the static and default IP addresses and I’ve gotten conflicting results which I can provide if it’s helpful.

If this matters, when I type ‘ipconfig’ into the command prompt, there is no default gateway, and I get the same error when I put in the IP address into the address bar of a browser. I also don’t know if I’m using the ethernet cord that came with the router, so it’s possible I might need a different one…this one is a basic cat5 cable. I have tried multiple IP addresses and confirmed also that I’m not using a duplicate IP address registered elsewhere on my computer.

I’ve been back and forth with Multitech but thought I would ask the community and see if any of you wonderful and awesome people have any ideas I could try since I’ve spent all day just about and I’m still on step 1.5 of the user guide (which would be really funny if it wasn’t so sad!) They have confirmed for me that there is no special drivers or software I should have to install. Thanks in advance!!

Edit: Not receiving a response when I ping it…tried new ethernet cable…Support says it has to come back in for repair. So essentially my unit was DOA :frowning:

Gateways do not interfere, other nodes, sparking engines, switching appliances etc do. So while there might be less interference in the countryside that does not mean there isn’t any.

A technicality - I am fully aware of this. I meant that there is no LoRaWAN traffic interfence from other nodes.
Where I usually have my gateways in Amsterdam, I quite frequently see KPN nodes broadcasting all over my space at SF12 for 3 seconds! I can detect no other LoRa packets where I live.

Do you have any information on the packets with CRC errors on both locations?

Since the device wipes the logs on reboot, I don’t have the original logs for the data shown on the graphs above. I’ve had a look through the log before and I’ve seen plenty of CRC errors, but I don’t know how much is “normal”.

What would be the best way to go about logging this? I can then start gathering logs to go along with my other data.

The MTCAP uses your packet forwarder, and the Kerlink uses the generic Semtech forwarder.

So my colleague was at a convention and he asked a representative (can’t remember which company), who commented that they’d seen a lot of packet loss with the MTCAP, but only on The Things Network.

Now, I have no idea whether this is true, but I’ve got to leave no stone unturned. This whole time I’ve only ever used @kersing’s packet forwarder, without testing the built-in forwarder to see if there is a difference. So I reset the MTCAP and followed Multitech’s instructions with the EU gateway-conf file. The gateway_ID is in the local_conf.

However, when I go to start the forwarder… Nothing happens. I had a misplaced comma in my local_conf…
Once I’ve got it working correctly, I’ll post my results in a few days.

@kersing what’s the reason for the tx_lut_XX changes in the multitech_overrides.json? Should I copy them into my Semtech packet forwarder setup?

Those values are based on a configuration MultiTech provided at the time for the Conduit. As the AP is different anyway you can ignore them.

1 Like

Looking forward to the results. I started using (and providing) an alternative forwarder because I noticed packet loss when using the (then current) MultiTech software. It would be ironic if I now introduced that issue in my software.