Home |
Search |
Today's Posts |
#7
![]() |
|||
|
|||
![]()
Howdy,
I'm interested in low level portability. The end-user portion the transmission standard is expected to be implimented in chips. But the the data-originator should optimize existing infrastructure. From that standpoint: Browser-net-WebServer-Database-net-proxy-radio-wireless-client. The segment between the database and the proxy really wants to be able to use IP as a network layer. If I was looking for a one-off solution I could cronjob an RCP. I would rather have a protocol instead because I want intercompatability between implimentations. As a transmission standard I am thinking more layer 2 and up. Bandwidth usage should scale with the layer 1 medium. I don't need much band-'width' but would happily encode the bits on whatever frequency is most appropriate. 56Kbps would be nice but I could probably get away with 4.8Kbps The actual frequency range I settled on will be dependent primarily on associated hardware costs. (on the client side, not the publisher side) I am guessing the L-band might be servicable considering there are already buku recievers units built for consumer GPS. Feel free to enlighten me if I'm totally off the mark there. This service doesn't compare to GSM or equivilant. The protocol should not disclude terrestrial transmission, though sattelilte would be prefered due to fact that the customer base is global, potentially rural in many cases, and generally atypical of the GSM customer. I do have unique identifiers (for the data, as well as a client-id) that must be transmitted. These unique bits are expected to be read by a chip on the client side. I am guessing that one of the issues here is that FEC seems to intigrate layer 4 and layer 1 of the OSI model into a single service. So wireless transmission and terrestrial transmission are a bit backwards. On copper, bits are reliable so error correction is mostly just CRCs. Dropping a frame is rare. With wireless the frequentness of dropped frames makes heavy error correction and transport control part of layer one. This makes following the OSI model from a development standpoint at least a little redundant past layer 1? Am I seeing that part of the issue clearly? Thanks for the Ref to the ATSC, that will probably clear up a lot of my questions. You are correct, I do need to learn more about wireless communications. That is why I posted here. :-) I'm guess what I'm looking at is writing a presentation layer protocol, encapping it in UDP, the proxy then strips the UDP header and reencaps my protocol into some form of ATSC protocol, which is then dumped into a modem buffer. Whalla, IP to end user. (if only it was that easy) -Matt |
Thread Tools | Search this Thread |
Display Modes | |
|
|
![]() |
||||
Thread | Forum | |||
Newbie legal/detection questions | Scanner | |||
Amateur Newbie Questions: Homebrew RF Test Equipment? | Homebrew | |||
The FAQ (Well, Question 1, at least) | Homebrew | |||
The FAQ (Well, Question 1, at least) | General | |||
Newbie questions from southern Utah | Shortwave |