I am looking to explore these three physical parameters:-
1.phy[].fec
2.phy[].feclist
3.phy[].errorDetection
where can i get detailed information including implementation as well?
In general, you can type help followed by the name of the parameter (e.g. help phy[].fec) to get more information about that parameter.
The PHY parameters are dependent on the specific modem implementation. You can type phy[CONTROL].fecList and phy[DATA].fecList to get a list of forward error correction (FEC) codes available in your modem.
For more information, you should contact your modem manufacturer.
Related
I am currently using dronekit-python to implement somewhat of a Mission Planner clone, as an API. I've generally been able to replicate most important features from Mission Planner; however, some features don't seem to be present.
One such feature is reading live servo outputs, which can be done in Setup > Mandatory Hardware > Servo Output (image below). I have been able to emulate getting/setting the output's function, min, trim, max, and reversed values through parameters. However, I cannot seem to access the live position values through dronekit. How would you go about this?
A second feature is reading specific values from the plane, beyond the class attributes present. This is available in Mission Planner when double-clicking a value in the Quick pane in order to change what measurement is displayed (image below). For my use case, I'd like to specifically access battery_voltage2 and battery_remaining2, as these are vital measurements for our system. I tried using vehicle.battery in dronekit, but this seems to only display data from battery 1. Any ideas?
Thank You so much for the help!
It might be possible to get the battery information and other information from the drone by using Mavlink messages. For battery information, look at the BATTERY_STATUS (#147) Mavlink message. For servo information, look at the SERVO_OUTPUT_RAW (#36) message.
In order to receive these messages, look into using message listeners from dronekit-python. You should be able to receive and parse the Mavlink message.
In general, you can use message listeners and the dronekit-python message factory to receive and send Mavlink messages, which allows you more control than some of the built-in dronekit functions. If you decide to control the drone this way, though, be careful because it's pretty easy to mess up your logic and have the drone behave unexpectedly.
Hope this helps!
In a professional context, I have to use the vl53L0x. This sensor was released recently, along with it's API, meaning that there's no help on the internet yet :
http://www.st.com/content/st_com/en/products/embedded-software/proximity-sensors-software/stsw-img005.html
This API contains some source and headers file, that I compiled with the gcc. It works fine, despite clearly lacking comments. I flash the memory of a stm32 (NUCLEO-F401RE), which controls a vl53L0x sensor via an I2C bus. I now want to add more vl53L0x sensors on the same I2C bus, and refer to this document (if you want to read it, go directly to the bottom half of the page 5, the wiring is already done) :
http://www.st.com/content/ccc/resource/technical/document/application_note/group0/0e/0a/96/1b/82/19/4f/c2/DM00280486/files/DM00280486.pdf/jcr:content/translations/en.DM00280486.pdf
The principle, that I already applied on other sensors, is that they all start with the same address. You then have to activate one, change it's address, then activate the next one, change it's address, etc.
Unfortunately, ST Microelectronics didn't publish the list of the I2C registers, so I have to use their API to control multiple sensors. The document linked above explains how to do so. Among other things, it specifies :
In vl53L0x_platform.h API file
• Set VL53L0x_SINGLE_DEVICE_DRIVER macro to 0 so that API implementation will
be automatically adapted to a multi-device context.
I looked everywhere in the API folder, I was not able to find any reference to a VL53L0x_SINGLE_DEVICE_DRIVER macro. Setting it to 0 won't change anything, as this string is not present anywhere in the API files. Did anyone run into a similar problem ?
I'm working on the same thing. It seems that you're further ahead than I am. However, putting this in my while(1) loop seems to make both the sensors work.
ResetAndDetectSensor(0);
TimeStamp_Reset();
The guide says that in order to use all the sensors simultaneously, you need to pull the XSHUT pin high for all the sensors, reset the timestamp and then pick up the sensor which actually detects something.
I am trying to associate the OpenCL GPU devices with NVAPI devices which I get using NvAPI_EnumPhysicalGPUs in the Multi-GPU system.
The thing is, I can use clGetDeviceInfo with CL_DEVICE_VENDOR_ID which is always unique and it is the best way, and I can retrieve the vendor from the NvAPI_SYS_GetChipSetInfo. But it is not associated with the NvPhysicalGpuHandle which I get from NvAPI_EnumPhysicalGPUs. Is there any way to associate this?
Of course, I can just use name, but this is not good.
There is a way to do it. In OpenCL there is a poor documented feature for some reason. You need to call clGetDeviceInfo with constant 0x4008 and it will give you the bus id for the following device handle.
cl_uint busID;
clGetDeviceInfo(device,0x4008,sizeof(cl_uint), &busID,NULL);
printf("%d",busID);
On NvApi side use NvAPI_GPU_GetBusId. Then you can associate the handles by comapring the buses.
I am using asterisk 11.9.0 and i want to generate an outgoing call.I found that for outgoing i have to make a .call file and place it in a var/spool/asterisk/outgoing.I am following the link below
http://the-asterisk-book.com/1.6/call-file.html#call-file-parameter
my code is same as given in the above link,the above example uses only single fixed number to call.
My problem is that
i have to generate an outgoing to a number fetched from database(outgoing to new number everytime),so how to write the code of .call file for multiple numbers outgoing and how to pass these numbers fetched from database to .call file from my extensions.conf
Is there any way to do that.
I am new to asterisk.
Any help would be appreciated.
You can use vicidial.org software to do that things.
Note, it is very bad idea do outboudn dialler-like app in asterisk without understanding asterisk logic and very-hi skills in programming/database.
For more info you also can use this page
http://www.voip-info.org/wiki/view/Asterisk+auto-dial+out
Might be easier using WombatDialer as it has a plain API where you can tell it what you want it to do and it will take care of the rest. We have a plain set up for outbound and it took maybe a couple of days from zero to what we have now. ViciDial would have been overkill.
On why rolling your own is not a great idea, the Wombat manual is quite clear: http://manuals.loway.ch/WD_UserManual-chunked/ch01.html#_why_was_wombatdialer_created
You could also use the AMI (Asterisk Manager Interface), would be easier to program with a deamon running in the back to control what gets dialed and the responses to those dials. Mora info here https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=4817239.
I want to write a client program that communicates with the application server via standard TCP/IP. The client can speak to the application server and be authenticated by simply speaking in a specific text based protocol. The traffic will be encrypted, but there won't be username/password. If another application tries to communicate with the application server and if the application doesn't use the correct text based protocol, the application server will silently discard packets.
Waiting for suggestions.
You can use a simplified version of TLV (Tag Length Value).
The basic idea is to define a set of message types which are represented by a code of fixed size (the T for Tag). Depending the type of message the contents of it (the V for Value) can very so you specify its length (the L for Length) before the contents. The Length field also has fixed size
Suppose you have one message used to send user data to the server. You can define a message like:
0x01 0x0018 0x11 0x0003 tom 0x12 0x000F tom#hotmail.com
Tag: 0x10 User data. Length: 0x0018 Value: sub tags
Tag 0x11: user name Length: 0x0003 Value = tom
Tag 0x12: email. Length: 0x000F. Value = tom#hotmail.com
Edited:
I was about to forget: Merry Christmas :)
Take a look at BEEP.
You might also find some good examples at four.livejournal.com; he's gotten good results writing an HTTP parser using the Ragel state machine generator, and also by hand.
if your not comfortable with the limitited functionality (verbs) provided HTTP just add more verbs. This is what the REST architecture is for.
If you want to continue down your path of folly (your talking about reinventing HTTPS), then use protocol buffers to create a protocol -- it will save you hours of grief.
-- edit --
If your objective is to understand the programming involved with web-servers, you might want to read apache's code dissected by the FMC group into a collection of models. I have read this PDF multiple times -- it is an absolute gold mine.
All the other comments are good, and stuff like BEEP, or doing some custom TLV encoding can get you along way, as well as using something like Google protocol buffers, but none of these are what I'd really call real simple.
A very simple text based protocol could just use a new line as the message delimiter. This is how IRC does it. Its not the most efficient, but if your messages are reasonably small it could work quite well. You could also prefix your message with a much shorter line telling the receiver how long the next message is.
If you want to use a light framework, look at libevent. It can assist in your IO and do line delimited reading for you.
If the language (protocol) is not already determined for you, then that is what you should design first, or look at something that already exists - XML, JSON chunks, netstrings, etc.
You can look at some of the sample code from TCP/IP Sockets in C.
It has many examples of doing client/server communication in C. Without more details, it's difficult to know what you really want to handle...
For communicating between bespoke apps, you can just send your text format in TCP packets. You can use an extremely simple text format, but you should make sure that it starts with some text that clearly identifies to your server that it is a packet from your client, and not from an imposter. (Clearly this is not terribly good security, but that's not the point of your question).
A good place to start is to use XML for your text-based format. This is dead simple to write/read, and is flexible and extensible so you can easily add more information to your packets at a later date - the biggest thing you can get wrong is to use a communications format that can't be extended!
Once you have basic comms working, you can enhance the format to send more information, add encryption and other security measures, and consider moving to a binary (more secure, more compact and efficient) format. BUt you can work your way to this stage in small easy steps.
So the right direction:
Get two programs talking via TCP. Just a simple packet with the text "bob" in it is enough at this stage, just to verify that the messaging is working. There are any number of simple tutorials on the web to get this going, and it's just a few lines of code once you work out what's needed.
Then build your packets. Start with the simplest approach that gives you a unique ID (to verify that the packet is from the right program) and a means to add new data to the packet easily in future. Xml is ideal for this. Don't worry about security, just concentrate on the actual "conversation" you wish to convey between the programs - what data they wish to exchange and how to encode it.
Step by step improve the communications protcol until it achieves what you want - smaller, faster, binary, more robust, fault tolerant, secure, etc. Each of these steps will be an interesting little challenge and by the time you've done them all you'll have learned a lot.
Look at the chapter on text protocols in 'The Art of UNIX Programming' by E S Raymond. It covers a lot of the relevant ideas at a high level, with good examples, and explanations of why they are good examples. It mentions BEEP.
I've recently read a book on this topic. It's called "TCP IP Sockets in C", by Michael J. Donahoo and Kenneth L. Calvert. You if you can afford it, it's a nice tutorial/reference book to have.
If you'd like you can try create the client<->server pair in Java, as it is easier to grasp the idea, and then rethink the solution at a lower level in C.