Hi Antti,
Well, it wouldn't really help you at all, because, what you're going to do?
Legally, you could only use the ISM bands (which are already congested).
Or you'd need to buy a licence for licensed spectrum so that people can
use that spectrum; you'd need some central station to arbitrate access
to the expensive spectrum you've bought, because in a dense situation a
"oh, everyone just uses this whenever they please" is not a solution.
People that buy licenses for spectrum, offer infrastructure to control
medium access and route data around have a name:
They are network operators. And it's unlikely you'd build a network that
is better at being efficient in using spectrum to transport many
people's data than LTE.
So, whilst adding another piece of (universal) radio equipment to your
(fixed-purpose) radio equipment is an interesting thing, it won't solve
the problem of spectral congestion. You could argue that your GPS data
is "really not much data at all", and you'd be absolutely right. To
transport "not much data", you can use "not much bandwidth", or a very
high spreading factor, and get your data across a long distance at
limited transmit power (which is a legal necessity in ISM spectrum).
Now, the problem with that is, that there's really really many people
that are trying to do the same, at the same time, in an uncoordinated
manner. It's really hard to find sufficiently orthogonal spreading
sequences so that this works out positively. Simply because "not much
data" times "really many people within reach" becomes "pretty much total
data", after all.
In short: if you have cake, you can distribute it. If the cake is
already distributed, you either need to buy more cake (buy an LTE
license and operate an LTE network) or distribute the crumbs (trying to
find unused spectrum in the free-to-use ISM bands). Either way, there's
no free cake.
So, if you ask me, this (sharing a few bits of position information)
sounds a lot like the emerging problem field of interference modelling
of IoT sensor node networks, only made harder by the fact that the
network operator might not have reserved spectrum. As far as I know,
there's not been a great solution to that problem.
But, to be brutally honest, sounds like you're solving a "non-problem"
to me. It's been quite a while since I wasn't able to even log on to an
LTE network at an event because of too many people, and not because it
was in an abandoned subway station, well shielded from the LTE network.
In that situation, well, you're in that hole, and whoever gets your RF
signal is there, anyways. Many apps share data in the background – but
they do so in blatantly inefficient ways, generating kilobytes and
kilobytes of JSON or XML traffic where a simple exchange of two 32 bit
numbers would have sufficed. So, I'd rather try to use the
infrastructure for data transport that is given to you in a clever
manner (namely, minimum amount of transferred data, make the network
stack on your mobile device do actual quality of service prioritizing
instead of what handwaving s*** Android does these days, disable data
communication for all but important applications when getting little
chance to send data – these are all software modifications to be made to
a smartphone rather than additional hardware PLUS the software) than to
try and build up a parallel infrastructure.
Cheers,
Marcus
On 08/14/2017 06:31 PM, Antti Ruohonen wrote:
Thank you for your reply, Marcus. Your suggestion of an attachable
device is totally fine, actually very good idea.
So, this SDR device would be the medium to the software radio (app in
the mobile phone), which controls the device. How would this scenario
be possible to achieve the goal? Goal is to send (GPS) data over the
radio frequencies to update the app's map. :)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
