OSSIE Frequently Asked Questions
This page lists questions and answers that were asked in the OSSIE discussion lists or other venues.
Installation
What do I do if I can't get the omniORB source RPM from fourpalms?
Answer: The fourpalms site is occasionally unavailable. If this happens, try getting the file from http://opensource.nederland.net/omniORB/downloads/4.1.0/SRPMS/omniORB-4.1.0-1.src.rpm , and continue just as you would with the file from fourpalms. (added to 0.6.2 user guide 4/11/08)
USRP
How to install USRP only drivers?
Answer: Get GNUradio from:
http://gnuradio.org/trac/wiki/Download
On the stable branch or 3.1.* tarballs this should work:
./configure --disable-all-components --enable-usrp make
On the trunk
./configure --disable-all-components \
--enable-usrp --enable-omnithread --enable-mblock --enable-pmt
make
Other pages:
OWD
How do I add devices to the node definition?
I'm trying to create a new node in with OWD from the 0.6.2 vmware image. How do I add devices to the node definition?
Answer: Right click the device in the device list
OSSIE
Is there a Windows implementation?
Answer:
There is not a Windows implementation, and there are currently no plans to make one in the future.
The best solution for Windows users who don't have a machine they can install Linux on is to download VMware Player and use the OSSIE VMs, available on the downloads section of our website.
"Failed to resolve NameService?" error when running nodeBooter
Answer: Make sure that omniNames is running
The error persits even after starting omniNames
Answer: It appears the naming service is not starting. Could you send the contents of your omniNames.sh file? As an alternative to using omniNames.sh, you can type the following from the command line:
killall omniNames omniNames -start -logdir /home/<your user directory>/logs &
If you get an error message referring to log files, try typing
rm /home/<your user directory>/logs/omninames*
before running omniNames
Follow-up:
Using the commands on the command line worked and I was able to get the device registered.
killall omniNames
omniNames -start -logdir /home/Oss/logs &
Earlier my omniNames.sh was
killall omniNames [omniEvents]
rm /home/Oss/logs/omninames*
omniNames -start -logdir /home/Oss/logs &
When I deleted the [omniEvents], the script also worked fine.
Do OSSIE components typify the SCA's definition of an Application Component, which uses Base Application Interfaces?
OSSIE components and OSSIE CF::Applications follow the spirit of the SCA, but the Domain Profiles that specify the configuration of Components/Applications do not entirely conform to the specification. If you were to use commercial tool suites to interface with OSSIE, you would likely run into trouble (although Zeligsoft’s tools have supported OSSIE and may support the current version).
OSSIE does use all Base Application Interfaces to define Components/Applications, the limitation is in our usage of the Domain Profiles.
Do OSSIE Devices typify the SCA's definition of a System Component, which uses Base Device Interfaces?
While OSSIE uses the Base Device Interfaces, again, the limitation is in our usage of the Domain Profiles. As seen in the SCAv2.2.2 Extensions for CF::Devices, the JTRS notion of a logical device is different from the usage of a device in OSSIE. For OSSIE, a device interface is exactly that, an interface to access a particular device whose implementation is encapsulated within a CF::Device sub-type. OSSIE provides device interfaces to a GPP (in the form of a CF::ExecutableDevice?), a USRPv1.0 (in the form of a CF::Resource), and will soon provide interfaces to FPGAs and DSPs. What you will not find are logical representations of, say, an RS-232 device, or Ethernet.
Is there a way in OSSIE to generate custom Devices (for custom hardware), otherwise known as System Components as I currently understand them to be?
The OSSIE tools do not generate code for devices at this time. If the number of devices that need to be generated is low then it would be quicker to create the devices by hand by modifying the GPP example, as it is essentially already skeleton code. The skeleton code that needs to be generated by the script is very minimal, 5-10 lines each file, including XML, CPP, H and makefiles.
To incorporate a new device into the framework, the device implementation needs to be created and updated for the specific device. The best way to do this would by modifying the GPP device. Rename all of the GPP.* files to DEVICENAME.*, and change all references within the files to the same. Any interfaces that need to be custom (configure, allocateCapacity, etc.) will need to be written by hand in DEVICENAME.cpp.
Until the OSSIE tools support this procedure, here are the steps to do it by hand:
Now that the device (created from a copy of the GPP device) exists, the device needs to be referenced by the device manager. This is done by adding the device to a node DCD file, and by adding a dependency tag to the node SPD file.
The component(s) that are going to be deployed to the device need to reference this device dependency. The implementation in the SPD needs to be updated to include the dependency tag and the UUID of the specific implementation of the device.
Finally, for a waveform to run with some or all of its components on the new device, the waveform needs to be able to reference the device. First add the device to the SAD file. Second, add the device and the components that need to be deployed to the device to the DAS file. The DAS file is an OSSIE creation and currently acts as the deployment model.
All of the instructions listed reference the work that is being done here: http://ossie.wireless.vt.edu/trac/browser/ossiedev/trunk and here: http://ossie.wireless.vt.edu/trac/wiki/ML403 (To access the first link, register at http://ossie.wireless.vt.edu/trac and email your user id and request for read access to ossie at vt dot edu)
The process that is outlined in the paragraphs above was used to create the XilinxFPGA device and add it to a waveform. The source directories under …/ossiedev/trunk/ that will be of interest are the following:
components/TxDemo
platform/XilinxFPGA
nodes/default_ml403_node
waveforms/ml403_ossie_demo
This work is not release ready at this point, so we won’t be able to field a lot of questions, bug fixes, etc. at this point. However, the source provides a good example of what hooks need to be added when creating a new device. Additionally, the process for creating and using a new device which we have outlined is somewhat involved, and will be better explained and in more detail in Matthew Carrick’s thesis, which will be available within the next month or two.
If OSSIE does not provide the functionality directly to generate Devices, how difficult would it be to write a script which could generate the skeleton C++ code, makefiles, configure files, and xml spd and scd files for a custom device?
The skeleton code that needs to be generated by the script is very minimal, 5-10 lines in each file, including XML, CPP, H and makefiles.
Further, how difficult would it be to install a custom defined device into the OSSIE environment so that it could be used in the OEF as part of a waveform application?
Currently, the legacy OSSIE Waveform Developer (OWD) allows creation of new nodes or node configurations (each “node” consists of a directory, by default located under /sdr/nodes/. Each node directory contains device manager XML files that specify the set of devices available at that node). OWD can be used to create nodes that use existing devices (this would include new devices that you develop, once they are built and the binary and XML files are installed in the appropriate directories under /sdr/). Lab 7 provides an example of creating and using a new node configuration. We are adding this feature to OEF.
What limitations are there in OSSIE as far as defining component Ports? Can I have ports of multiple data types, or ports of a CF type? How would I create a custom_ports component in OSSIE? What is the easiest way to create a custom port type which would be defined by someone using OSSIE?
OSSIE currently supports components with multiple ports, and the ports can be of any data type for which an interface is implemented.
To create a new interface, we recommend modifying the IDL in customInterfaces and then writing an implementation in C++. We do not recommend adding to the OSSIE::standardInterfaces IDL to maintain a consistent set of "standard" interfaces.
We most recently used the basic approach described above to develop interfaces that use metadata for our work on the 2007 smart radio challenge, which effectively implemented a port with multiple data types. The student who implemented this recalls that the process was relatively straightforward. The component simply needs to use the custom port's "pushPacket" method (or equivalent) to handle the information. The work we did for the smart radio challenge with standardInterfaces-MetaData is at: http://ossie.wireless.vt.edu/trac/wiki/MetaData and http://ossie.wireless.vt.edu/documentation/system/standardInterfaces-metadata/
The easiest thing to do would be to browse the revision history and source code here:
http://ossie.wireless.vt.edu/trac/browser/ossie-sdrf2007/system/standardInterfaces-metadata This currently requires that you first register at http://ossie.wireless.vt.edu/trac and then email your user id and request for read access to ossie at vt dot edu.
Are OSSIE Software Component ports and OSSIE device ports of the same object type in OSSIE? If not, how does each type differ and how difficult is each to create when building custom ports, possibly with custom port types?
Component and Device ports are not of the same object type, but they support the same set of port types. If you want to add to the set of available port types, then you must define your own IDL. We do not recommend adding to the OSSIE::standardInterfaces IDL because it will only muddy the waters of our notion of a "standard" interface. The OSSIE::standardInterfaces defines port types for all primitive types (i.e. int, double, char*, etc.). If you feel that you need to expand on this, then you most likely are not using primitives, but user-defined types. If you are using primitives, but feel that you need additional functionality within a port type, then you can extend the OSSIE::standardInterfaces in way that is similar to the OSSIE::standardInterfaces-metadata types described earlier.
The use of ports in OSSIE is a subset of that allowed by the SCA. In the SCA, all component types can also be port types. OSSIE supports this interpretation, but does not promote it because we choose to physically separate the notion of ports from components to avoid confusion.
