I am creating a REDHAWK device that outputs either 16 bit signed complex samples, or VITA49 packets. I want the device to be told which output type it should provide when it is allocated.
How should I go about this?
Should I just add a simple property to the front_end_tuner_allocation struct?
Some other recommended approach.
Is there an example that I might look at?
ANSWER
I was able to speak with an experienced REDHAWK developer.
Apparently in situations where the device is capable of producing different data flows then separate Device node specifications should be created. This means that the output port to be used will be dictated when the device is started and should not be configured at run time.
This actually makes sense given the life-cycle of the device and the component receiving the data.
This is how I rationalize it, the component won't be able to control the device until the allocate-capacity is performed. So there would be no way for the component/waveform to setup the device ahead of time.
Related
I am writing here because I am having some problems understanding some key concepts regarding kernel/drivers development.
First, I am going to try to describe what I want to achieve:
Develop a driver that uses the SPI to communicate receiving the payload from user space (I cannot use spidev because I pretend to transparently add some info to the payload before sending it). I want to load the module manually (insmod).
The problem I am seeing: I do not know where or how to specify my interface. If I define the interface within the device tree, is it mandatory to include the compatible field? I ask this because the driver will not be included within the kernel modules as it starts up... Maybe there is not a problem with it. In the examples, I found about spi they only speak about the BUS, Chip Select... but they do not mention MISO and MOSI, so I guess these must be defined by the device tree or maybe since you specify the bus the definition of the rest of the pins is straight forward... I would like to understand this.
Thanks in advance.
Best regards,
Fulgo.
I feel like I am missing something, all of the VITA49 examples seem to be using TCP or UDP.
Is there a specification or standard way of providing VITA49 packets for consumption?
Should I be performing the conversion and providing standard complex samples with Keywords?
I have looked at the rh.vita49 loopback demo waveform, and the MSDD device source, as well as the sourceVITA49 and sinkVITA49 component. All of these use either a tcp or udp packet stream.
If the standard is to use sockets to pass VITA49 packets, then where should I be looking to understand how to construct a device that adheres to the standard?
ANSWER
I was able to talk to an experienced REDHAWK developer.
There is no standard, per-se, with that said the approach I took was to make use of the socket.sourceVita49 asset. This asset consumes the Vita49 packets and inserts appropriate keywords etc based upon context packet. This required me update my device to support setting the hardware up to send Vita49 via TCP. This actually provided an easier solution for me, as I wasn't having to bust the VRT apart.
Examples:
The best example I found of consuming Vita49 was the MSDD device asset.
NOTE:
After reviewing the MSDD, it does not look to be too difficult to create a device that consumes VITA49 VRL,VRT packets and produce time stamped samples. I will be investigating that in the future.
I’m creating an IOT device with some unusual needs when compared with typical home automation. I wanted to ask if anyone knew of a mesh protocol (Zigbee, Thread, BLE Mesh), that might be able to achieve this user experience:
When someone turns on their device, it looks to connect to a mesh network, comprised of other devices they have previously “friended”.
If no network is found, it creates its own mesh network, available for other “friended” devices to connect to, when those devices turn on.
If the device creates its own mesh network (as in behaviour above), but no one connects to it – and then the device finds a different network with more than one friend on it, the device should kill its own network in favour of connecting to the other.
I’m expecting that there will not be a “master” node who has “friended” every possible device that wants to join the network – I’d like the possibility for “friends” to bring their “friends”, to also join the network.
If a partition in the network occurs (this is very likely to occur in my use case), the network should automatically re-form when the devices are close to each other again.
All devices are expected to be identical in function, size, software – so BLE Mesh is probably not suitable given it needs a “Provisioner”?
Messages transferred will be bespoke to this application – ruling out Zigbee’s Application Layer?
Messages will be small in size, so data transfer speed is not a big concern.
I believe from what I’ve read that Thread is probably the most suitable for this use case – but wanted some other opinions to see what the best choice might be?
Seems to be a bit of a mine field to fully understand the ins and outs of all of these mesh protocols!
I believe Thread/OpenThread addresses all of the use case items you listed above.
Difference between an API and a device driver
From the above link i read that API is like a specification that describes what to do, while a driver is an implementation that describes how to do it.
Now, i couldn't find API in linux for display, audio etc.I have also read on internet that linux provides device files to interact with device drivers. we can communicate to devices by writing or reading in those files but as written above API is the specification that describes what to do and API layer is missing here.so, i don't know what commands to writes in those files to interact with devices. ex-rasterize a image on display with the help of these device files.
Device files are just a practical way to communicate between user space and the kernel. Some device files (most notably, block devices) have a uniform API to them, but that's kinda besides the point.
For most standard operations, you would not interact directly with a device file, but instead use a library, exposing a documented API, for doing what you want. So, if you want to play sound files, you'll use, e.g., libjack, or even a higher abstraction layer, such as gstreamer or libvlc.
It is possible, and even likely, that those library use a device file for their actual output. You need not deal with that, unless you want to.
In other cases, you do want to open the device file and interact with it. In those cases, you need to read the relevant documentation to see how to do that. Some device files merely accept read and write requests. Others, such as tty devices, have ioctl commands that modify how they work. The man page for the relevant device will tell you what you need to know.
In general, many treat device files as extension of the kernel's API. In fact, many call the ioctl command "user defined syscalls". In all cases, just read the documentation to see what you need to do.
In Bluetooth, specifically 4.0 LE (if this changes anything), what is the way to send data both ways, from master to slave and from slave to master?
What kind of protocol is it better to design? Can you please provide an example of an application level protocol that is typically used in this scenario?
In this case, should the peripheral run two services, one used for sending data to the device and another to receive data from the device? (The "device" is the peripheral/slave).
The most forward way of doing this would be to define a custom service which defines the data types and fields and access you need as characteristics, and implement this on both the peripheral and central. If you are looking for a symmetric system, you can implement the same service on both sides. If there is differences in how the two devices access/send data, you can implement two different services, suiting your needs. Either way, you will need both the slave and master peripherals to support both GATT server and GATT client.
Depending on what you want to do, you could either push data using notifications (unconfirmed, you may miss updates on the receiving side) or indications (confirmed, the receiving side will have to acknowledge the push), or you could pull the data using read commands. You could also combine these in various ways, and you could implement access to different data in different ways in your service(s).
I recommend taking a look at the different Bluetooth Low Energy vendors' dev kits and APIs, as well as the different phone/tablet APIs and examples, depending on which platform you aim to develop on/ are familiar with.