average user wont be able to, but many hobbiest users will.

once the code is done and an example circuit is created, its just copy and paste. hell, I'd do a sample just for grins. I find the whole idea WRONG to put limits in the code like this, so I'd be happy to write some sample code that will remap gps data on a serial line. but seriously, its not at all hard.

Guess what, you're that Joe Sixpack. They've successfully convinced you that it's not worth the effort of trying.

gps modules almost always use low speed serial (ttl) comms.

it would be trivial (50 lines of C code, maybe much much less) to have a cpu (even attiny) in the middle between the gps module and the rest of the brain. when the x,y values come back and its inside a 'nfz' it could easily be remapped (in simple ascii) to NOT be in nfz. perhaps if you are near a nfz, it would go into auto-offset mode and add a fixed x,y value so that it thinks its miles away. then you compensate for it at the ground level when you program its course.

would not be hard at all.

waste of time to try to disallow x,y values for things like this. anyone here who spent a few weeks on even a simple arduino could do this remapping in an afternoon.

*secure* is my big issue, these days. without security being well thought out, iot stuff can be a disaster. and I'm not seeing a lot of thought (not really) being put into the whole iot stuff, which worries me a lot.

snmp is a red herring. it won't ever be used for iot and doesn't make sense there, other than to manage the systems that hold the sensors. (speaking as a seasoned snmp guy who spent 25+ yrs doing snmp for lots of big co's).

one data point for you: in the Eiot stuff that I worked on (e = enterprise) we used 'usb sensors' (analog and digital sensors that went to an a/d dongle, then into usb, then into a usb-ip bridge of sorts). this feed power (poe) to the sensors using existing poe infra at big companies and you only have to have cat5 cables to get power and ip connectivity to your sensors.

iot is a superset and includes low-end stuff (for us consumers) and high-end stuff for industry; and when its for industry, its 'eiot'.

(ob disc: I spent some 25+ yrs in the SNMP field; now working in IoT, at least I was until my last gig finished)

snmp has absolutely zero to do with IoT. snmp is a good (...) netmgt protocol that is very lightweight, standard (well...) and has been around for a few decades. as you know, its poller-based, mostly, with traps there as accelerants to help pollers zoom in, faster, to any events worth knowing about. snmp sucks for streaming loads of data upwards and really has no mechanism for that. has no mechanism for filtering at its source or data compression for transport.

what you want for IoT is to have, essentially, endless streams of source data going thru 'smart filters' along the way (last place I was at, we used 'hacked routers' to do our smart filtering) and then getting to some analysis node. the node may just collect data or it may run some rules and decide if a 'talk back' is needed or some control/feedback loop to change something in the real world.

the 2 cases are really different. snmp is 'slow' and never EVER realtime (not even traps, technically) and is mostly poller based (req/response). IoT is 'transmit continuously' based and MUST have low latency and a reliable (tcp) transport for all its crucial data points.

sorry, but IoT is nothing - NOTHING - about cellphones or mobile data. those come from USERS. this is not about USER data. its about DEVICE data.

think 'sensors' and you will be headed in the right direction.

right. and one solution (that home users won't like but industry will) is to use usb sensors.

huh? yeah, usb sensors. and usb/ip transports. and PoE for power.

lower end sensors are analog. a cpu will convert it to digital and stream it to some remote sink.

mid-end sensors will be digital (pure) or digital-usb (transported).

high-end sensors will be native ip-based.

all 'ends' are covered.

internet of things (from what I've seen, working on it at a big-name comms company) is all about SENSORS and REALTIME data.

if you are streaming loads of sensor data to some sink, somewhere, that is the current classic example or use-case of IoT.

expect this to be worked out more in industry than at the consumer level. the consumer level is getting the buzz (at forums like this) but in industry, they are talking about expensive sensors (high end a/d systems that robots depend on), power over ethernet to distribute power to the sensors and also ip connectivity, along with (believe it or not) usb-over-ip routing to send sensor data over ip networks.

that's nothing. I have a bit of the IoG (internet of ghosts) working:

% ping elvis
elvis is alive

see! I told you!!

...or a samsung 'smart' tv.

(from what I've heard. wish this was actually a joke, too)

I have not seen it mentioned here, but there is also EIoT; E is Enterprise. a whole nuther thing. some companies want sensors (think: industry) and they send huge volumes of test data 'upwards'. the trick (from one vendor, at least) is to data-reduce it intelligently and then forward it up toward the root. you don't have to store the data (per se) but by smart filtering, you end up forwarding only 'useful' data and it can be acted on immediately.

so, the consumer end is only a tiny part of it. the real part is for industry, but no one seems to remember (or realize) this.

use the proper name, at least:

"Jesus H. Vishnu"

damn. some people....