I would like to know if there is any protocol document that specifies "air-interface independent"/ AI2 protocol like ISO/IEC documents or RFCs. In particular for GPS domain.
Thanks in advance...
Regards,
Aadishri
You can start by reading the SUPL spec provided by OMA
Related
I want to check if there is support for endianness(little endian/big endian) in plc4x modbus library to process the response based on that . I could not find any documentation or example on how to use if it exists.
So, request to same some links here if available.
Right now we currently don't support this, but we are aware of an option to fix this. Till now we haven't implemented any support for this mainly because none of our core contributors has access to such a Modbus device. If you have one particular device in mind, could you please name the Type an model or if you could provide us with such a device ... perhaps we can come up with an implementation.
I have difficulties finding PDF/A-1, PDF/A-2, PDF/A-3 specifications. Is there one? Or is it just description of what it has? There is no trouble finding version(v1.4...v1.7) specifications.
Thanks in advance.
Yes, there are of course, but you have to buy them from ISO,
e.g. here for PDF/A-1
Then Links are at the bottom of the relevant Wikipedia Article
Is it possible to use google protocol buffers as the serialisation mechanism when only one end of the comms channel is using it?
ie given a client that needs to speak to some 3rd party server or hardware that communicates in some defined message byte structure.
is it possible to specify the exact byte structure to expect using the protobuf IDL? Or does protobuf use it's own byte packing format therefore both ends must speak using protobuf protocol?
If not protobuf is there some library that would achieve this?
No. Protocol buffers has a very rigid layout, that cannot be changed, and is unlikely to match the one you are using unless it is secretly using protocol buffers and just not advertising that fact. The encoding is documented here.
As for alternatives; that would depend hugely on what platform / language / framework you are using. It would not be unusual to find you have to write your own tools for talking the required protocol.
I'm looking to create a DLNA media server type of thing in Android. I've found myself a UPnP library for Java called CyberLink, and I'm looking to implement the DLNA interface for a M-DMS, or Mobile Digital Media Server, which has a quick description here:
http://www.dlna.org/dlna-for-industry/digital-living/how-it-works/dlna-device-classes/mobile-digital-media-server
The problem is that I can't find the actual technical specification for such a device. I've put in a lot of effort Googling, so please don't throw a 'JFGI' at me. I ran into a forum post that implied I might have to pay for access to the specification, but it was very vague:
http://www.ps3mediaserver.org/forum/viewtopic.php?f=4&t=3608
The link that was posted as the apparent solution is also broken, and I can't find any similar document on the current UPnP website.
Does anybody know where I can find the DLNA specifications? Or perhaps an alternative solution to implementing it myself? Any help will be much appreciated!
Full DLNA specs are available only to DLNA members and dearly paid for. The guy in referenced forum post is mixing things up. UPnP is not a "dlna doc". DLNA is a refinement of UPnP, a set of rules and restrictions in the name of interoperability. A good half of the DLNA specs is just a verbose listing of allowed media formats, subformats, sampling rates, bitrates etc. Whereas UPnP just specifies the abstract device interfaces. The link is correctly
http://upnp.org/resources/upnpresources.zip
and standardizeddcps is a subfolder there. DCP stands for Device Control Protocol, aka the abstract interface which the device must implement to participate in UPnP network. You would be interested in arch-DeviceArchitecture document to understand UPnP network in general and then MediaServer* folders, most importantly av-ContentDirectory which is a core service to provide DMS per DLNA specification. And yes, Intel Device Spy is absolutely essential tool. Wireshark will be your friend too. Reverse engineering is a daily bread and DLNA specs won't help you :)
The DLNA spec is now available to anyone -- you do not need to be a paying member to download.
From the DLNA.org website: (http://www.dlna.org/dlna-for-industry/guidelines)
Non-member companies may download the Guidelines using the form below.
**Please note that the Guidelines you download today are the most current published version of the DLNA Guidelines. When new Guidelines
are released, you will need to download the newer Guidelines to
receive the additional updates. Note that not all updates are
announced.
I'm not sure where to get the full DNLA specs but you could approximate the same info by using something like Intel Device Spy to see which services an existing M-DMS device publishes then use the service descriptions from the standardizeddcps directory in the docs available from the UPnP forum
You can get DLNA spec from the DLNA Organization, and for that you have to be member of the organization.
There is this DLNA compatible Digital Media Server (DMS) on Android platform and it is free for all Android platforms. It is tested with all leading DLNA certified TVs.
Pixel Media Server.
I am doing a project that extends SPICE. I need to send some custom data between server and client. I beleiev this is done by adding a custom channel to the SPICE protocol
I've got the source code, but it's huge and overwhelming. Can anyone give me a few pointers as to how to start, or direct me to a similar project so I can refer?
Thanks in advance
I suggest to start reading the "SPICE for Newbies" document, then moving to other documentation. It will give you some introduction on the architecture of SPICE, the protocol, standard channels, etc.
Available on spice-space.org/documentation.html
Since spice-gtk 0.15, and qemu 1.4.0, you can set up arbitrary channels by name using the "Spice port", see spicy.c code for an example of usage.