Christopher Hunt
Forum Replies Created
-
AuthorPosts
-
Christopher Hunt
ParticipantAny further advice? Thanks.
Christopher Hunt
ParticipantI *think* it was 1.6, but I’ve no access to the device as it is remote. The device was commissioned in July last year.
Christopher Hunt
ParticipantAfter a reboot, the gateway was fine again. It’d be great to understand how this may have happened. I’ve certainly not seen it before. Thanks for any info.
Christopher Hunt
ParticipantThanks, Jason – any chance that these builds can be made available from the Multitech repositories? I’ve not yet set myself up for building my own images, although of course, I will if that’s what it comes down to. Clearly, there’s potential interest for mDNS on the Multitech devices. Thanks.
Christopher Hunt
ParticipantThanks Jeff. I did dig a little further – it appears that the architecture name that OpenWRT uses is formatted differently. They use
arm_arm926ej-s
whereas Multitech usearm926ejste
. Addingarm_arm926ej-s
to/etc/opkg/arch.conf
locatedavahi-utils
but it then tripped up looking forlibc
:Collected errors:
* calculate_dependencies_for: Cannot satisfy the following dependencies for avahi-utils:
* libc * libc * libc * libc * libc * librt * libc * libc *
…which doesn’t appear to be in the OpenWRT repo…
Would it be possible to ask around within your engineering group? mDNS would be super useful. Thanks for your help.
Christopher Hunt
ParticipantJust to add, in terms of what I’ve tried so far:
1. added to /etc/opkg/mlinux-feed.conf:
src/gz openwrt-arm926ejste https://downloads.openwrt.org/releases/packages-18.06/arm_arm926ej-s/packages
2. ran
opkg update
and saw the above download the package info3. ran
opkg install avahi-utils
Unfortunately, step 3 yields, “opkg_prepare_url_for_install: Couldn’t find anything to satisfy ‘avahi-utils'”. This is mysterious to me… any help here appreciated as
avahi-utils
appears to exist in that openwrt package repo. Thanks.-
This reply was modified 5 years ago by
Christopher Hunt.
-
This reply was modified 5 years ago by
Christopher Hunt.
-
This reply was modified 5 years ago by
Christopher Hunt.
Christopher Hunt
ParticipantI realise that this is an old post, but I’d like to add that having mDNS available to mLinux would be super helpful for the lora components. In particular, the packet-forwarder in being able to locate a remote network server on my LAN. As it stands, I have to configure the network server to have a static IP address. I’d prefer not to as it means that I have to perform remote configuration on-site with my customer once the equipment has been provided to them.
Is there any chance that mDNS could be made available? I’m using varying versions of mLinux – the one I have in front of me is 4.0.1.
Thanks for any response on this topic.
Christopher Hunt
ParticipantYes, I did try the upgrade after a reboot.
Christopher Hunt
ParticipantI just tried upgrading to 1.7.2 from 1.6.4 via a reliable LAN connection. No cigar. I then thought, perhaps try 1.7.0 first. No cigar. Each time the UI reported that there was some error half way through uploading the firmware.
I then had to power-cycle the Multitech Conduit to recover. This is using AEP. Any further advice? Thanks.
Christopher Hunt
ParticipantThanks Jason. I’ll look at upgrading the firmware. So, just to confirm, I should expect to see the
tmms
field populated by the packet forward along with its receive packets…?Christopher Hunt
ParticipantI’ve deployed our most recent Network Server that now takes advantage of
tmms
. However, I’m not seeing that field come in either. Can you please advise on how I may receive the GPS time with a packet forwarder receive packet?Christopher Hunt
ParticipantHang on, shouldn’t I be able to use the GPS time (
tmms
field)? While not quite precise, it is certainly reasonable.`
tmms | number | GPS time of pkt RX, number of milliseconds since 06.Jan.1980
`
Christopher Hunt
ParticipantHi Steve,
Without precise timestamps, the Multitech and other networking hardware that it is connected to is, of course, subject to clock drift. Unless NTP is available then the observation times will be incorrect.
NTP and the internet, in general, cannot be assumed to be available for us. One of our projects in flight targets some sub-antarctic islands off New Zealand. There is no internet other than the occasional, assumed-unreliable satellite connectivity. Plenty of time for clock drift.
HTH.
Cheers,
-CChristopher Hunt
ParticipantHi Steve,
Thanks so much for the fast reply. Is the lack of precise time stamping a hardware limitation or software?
Kind regards,
Christopher -
This reply was modified 5 years ago by
-
AuthorPosts