I've installed the UHD device successfully on REDHAWK 1.9. I've tried adjusting the frontend tuner allocation property of the device, but when I try to run it, there is no activity showing up when I monitor the ports.
I don't even know if the redhawk device works properly because when I specify a random IP address, the device can still run normally.
So my question is: How can I use the USRP_UHD device in REDHAWK 1.9.0 to collect and demodulate a signal with a USRP N210?
I know the USRP is working because I am able to create and execute a simple demodulator in GNURadio, but I cannot replicate this in REDHAWK 1.9.
I'm able to start the component without errors, but nothing shows up when I monitor the ports.
You must first launch a Domain, create and launch a Node that contains a USRP_UHD Device, and configure the USRP_UHD Device with the IP address of the target USRP. Then, you must create and launch a Waveform with components that do the signal processing required (i.e. demodulation) and a usesdevice relationship that contains an allocation of the USRP_UHD Device.
Using Redhawk 1.9, I tested the behavior of the USRP_UHD Device with bad IP addresses to see if I could reproduce what you described. When I launched a Node containing a USRP_UHD configured with an invalid IP address, the following was reported:
ERROR:USRP_UHD_i - USRP COULD NOT BE INITIALIZED!
WARN:USRP_UHD_i - CAUGHT EXCEPTION WHEN INITIALIZING USRP. WAITING 1 SECOND AND TRYING AGAIN
ERROR:USRP_UHD_i - USRP COULD NOT BE INITIALIZED!
ERROR:USRP_UHD_i - Unable to initialize USRP!
I then configured the IP address with the correct value and the USRP_UHD initialized properly. Lastly, I configured an invalid IP address using the IDE, and the following error was reported in addition to the error above being printed again:
Failed to set property 'USRP_ip_address', due to Invalid Configuration. Unable to initialize USRP based on these properties
IDL:CF/PropertySet/InvalidConfiguration:1.0
Since you are not seeing this, there must be a problem with your setup. Describe your setup and the steps you take to launch the Redhawk USRP_UHD device, how you are “adjusting the frontend tuner allocation property”, and what do you mean when you say the Device “can still run normally”. It’s unclear if you are attempting to allocate properly -- are you doing this using a usesdevice relationship in the waveform SAD file, as is described on other SO posts?
Related
I am running a C# application on a ubuntu server 20.04 (running on a raspberry pi) which communicates with a controller. Both devices are connected via an ethernet cable and afterwards using a socket i search for its set ip 169.254.255.254 which remains always the same.
The application behaves the same as if the two devices are not connected throwing an exception "A socket operation was attempted to an unreachable network."
The connection worked on a raspberry pi os (latest version) but i can't use it because of a driver issue with a different component. I am also able to connect to the controller from a windows machine. Sadly i am very new to linux, ubuntu and networking and i can't figure out what could cause this issue.
Is there some kind of a setting that i need to set in order to be able to communicate with the controller?
If more information is needed please ask and i will provide.
Any IP within 169.254.x.x is problematic - in fact, according to this article, it indicates that the device is not connected to the network at all.
every since I updated macOS to macOS 12, I have trouble using CoreBluetooth.
In one of my apps, I will list all BLE devices using the CGCentralManager class.
This has worked for years. But now, when I start my app, the following output appears in Xcode:
[CoreBluetooth] No name or address
[CoreBluetooth] No name or address
[CoreBluetooth] No name or address
[CoreBluetooth] No name or address
[CoreBluetooth] No name or address
The macOS Console app has many messages like this (I don't know if this is related, the process is bluetoothd instead of my app):
Destroying pairing agent for session <appname>
Erasing session 0x7f795824af00 from SessionMap for "appname-2890-84"
Received 'stop scan' request from session "com.apple.bluetoothd-central-143-2" updateScanParams:YES shouldUpdateState:YES
Stopping scan as there are no remaining scan agents permitted to scan
If my app is not running, the bluetoothd process seems to be rather quiet. Once started, the bluetoothd process seems to have some kind of problem. The question is: which one?
Disabling the Sandbox did not change anything, so I don't think that it has something to do with missing permissions.
I also built a very basic example in a new app. I instantiated a new CBCentralManager and started scanning. The devices were discovered.
I my main app, no delegate function is triggered. None at all.
Did anyone encounter the same issue?
UPDATE: It appears that Apple has fixed the bug in macOS 12.3.
Original answer below applies to 12.0, 12.1 and 12.2.
It appears that Apple has updated macOS to behave more like iOS. The docs for scanForPeripheralsWithServices:options: say:
Your app can scan for Bluetooth devices in the background by specifying the bluetooth-central background mode. To do this, your app must explicitly scan for one or more services by specifying them in the serviceUUIDs parameter. The CBCentralManager scan option has no effect while scanning in the background.
Command line programs cannot ever be considered the foreground app since they are not a .app and therefore the background scanning rules apply. (This is conjecture, but I suspect that NSWorkspace.frontmostApplication might be used to determine the "foreground" application).
If background scanning is acceptable and the Bluetooth devices in use include a service UUID in the advertising data, then a list of service UUIDs can be supplied to scanForPeripheralsWithServices:options:.
If not, then you have to create a signed .app to use foreground scanning.
Some additional details and an ugly workaround for running a command line tool without a GUI as a .app (outside of the XCode debugger) can be found at https://github.com/hbldh/bleak/issues/720. This link is Python-specific but one should be able to extrapolate it to other environments.
I am Running RH 2.0.8 on CentOS 7.2. Attempting to control Ettus N210 using v6.1.0 of the USRP_UHD Device. From the IDE console, I can see the USRP_UHD recognize/initialize the N210. I can allocate a channel (1MHz BW, 2Msps) from the available RX_Digitizer.
My issue - I connect to dataShort out with the IDE Plot Data and never see any data or SRI updates.
Using wireshark, I see data being output from the N210 over the network connection, just nothing plots. Same issue whether I launch Device via node/domain manager or in Sandbox.
Similar issue if I launch a waveform with a USRP_UHD dependency - connects & allocates properly but I never any data sent to the connected component in the waveform.
Curious if anyone else has had a similar experience.
UPDATE 12/17/2018:
After installing RH 2.2.1 on a CentOS 7.4 system, the USRP_UHD device appears to work correctly out of the box. I'm able to plot data and SRI from the dataShort_out port after allocating an RX_DIGITIZER.
The output port of the USRP_UHD is what is called a multi-out port, which is slightly different from a normal BulkIO output port. The main difference is that the port will only send data over connections which have a connection ID that has been mapped to a stream ID. With the USRP_UHD, this is done via allocation and the allocation ID. Read more here.
To plot data from a multi-out port using the IDE, the plot must be connected to the port using a connection ID that has been mapped to a stream ID, which for the USRP_UHD means the connection ID must be identical to one of the allocation IDs. You can specify the connection ID using the plotting wizard, or you can create a listener allocation with an allocation ID set to the connection ID of the plot (either option will work). See the following resources for more information:
Port Plot Wizard
Plotting a Tuned Receiver
Allocating a Listener
Connecting a waveform to a multi-out port must follow the same conventions and connect using a connection ID that has been mapped to a stream. This can be done by adding an FEI device dependency to the waveform *.sad.xml file (see first bullet below). This can also be done after launching a waveform (that does not contain an FEI device dependency) by specifying the connection ID for the connection between the waveform and the multi-out port. The connection ID will need to be identical to an allocation ID associated with the stream of data desired, which could be a listener allocation or the original control allocation. See the second and third bullets below for more information on this method.
Associating a Waveform with an FEI Device
Allocating a Listener
Connect Wizard
Note: Though the links I've provided are to the REDHAWK 2.2.1 manual, the content is applicable to all versions of REDHAWK, including REDHAWK 2.0.8. The IDE features you will need are also available in REDHAWK 2.0.8. The 2.0.8 manual should have similar content if you'd prefer to use the older manual.
I am trying to create a distributed domain using RedHawk 2.0.1 and cannot find enough information on setting it up in the manual. I have two related issues. I want to run the domain manager on the same host as the IDE but run one or more components on another node. I see how to create a new node project but do not see how to specify the network location it should run on. I can add it to the domain but it simply runs two device managers on the local host. I also do not see details of how to make specific components run on the alternate node. Does this require manually adding allocation properies?
The related issue is that I would like to use a non-x86 node as the remote node. I am trying to use an ARM processor and following the instructions in the Sub$100 manual I was able to build and install the runtime system on my ARM, but I find that the GPP device's GPP.spd.xml still has x86 as the processor name while the prf.xml has arm as the required property.
The manual seems to indicate that the binaries for all nodes will be in the sdr of the domain manager, so am I supposed to copy the sdr entries for my arm gpp device and all components back to the sdr of the domain manager host and then they will be deployed back to my arm at domain and waveform launch?
Are there better detailed instructions for distributed domains somewhere that I am missing?
I believe the last supported version of REDHAWK for the Sub$100 project was 1.10, so we're in uncharted territory. That being said, let's take a stab at it.
The first thing you should do is make sure the /etc/omniORB.cfg file for your Domain Manager looks like this:
InitRef = NameService=corbaname::<external IP>:2809
InitRef = EventService=corbaloc::<external IP>10.3.1.245:11169/omniEvents
where should be replaced with your network IP (i.e., not localhost or 127.0.0.1). Restart the CORBA naming and event services with this command:
sudo $OSSIEHOME/bin/cleanomni
The next step is to configure your ARM device to point to the Domain Manager. Edit the /etc/omniORB.cfg file on the ARM device to match the one from your Domain Manager, even the IP address. Note that you don't have to start the naming and event services on the ARM device.
Now for running the GPP on the ARM device, you will have to create that node on the ARM device, since the Domain doesn't know about that device yet and cannnot access its filesystem. Page 16 of the 1.10 version of the Sub$100 document (http://ufpr.dl.sourceforge.net/project/redhawksdr/redhawk-doc/1.10.0/REDHAWK-Sub100-Manual-v1.10.0.pdf) has the instructions for installing the GPP.
Note that the newest version of the GPP is actually a C++ Device now, so the second step should be 'cd framework-GPP/cpp' and the third step should be 'git checkout 2.0.1'. Once that's installed, there are still a couple of more issues to take care of. First, run the following command:
$SDRROOT/dev/devices/GPP/cpp/devconfig.py --location $SDRROOT/dev/devices/GPP
That will configure your GPP to recognize that it is on an ARM platform (as long as your processor is an armv7l processor).
Next, run the following:
$SDRROOT/dev/devices/GPP/cpp/create_node.py --domainname <RH Domain Name>
That will actually create the DeviceManager profile that will contain your GPP.
The final step involves making sure that the node will be configured correctly. Check out Page 21, Steps 5. Basically you can remove the x86_64 implementation and replace any instances of 'x86' with an 'armv7l'.
As for your question about building your components, yes, you have to build them for the platform of interest and then install them to the Domain Manager SDRROOT. If you have a cross-compiler set up to build your components (and the framework), this will make your life a lot easier. However, if you don't, the workaround is to build the components on your ARM device, then install the XML files and the executable to the Domain. In order to make any components work with your ARM GPP, they will need to have an ARM implementation with a processor name that matches that of your GPP in their SPD.
I know that's a lot and I haven't run through these instructions in a while, so let me know if you have any questions or anything doesn't work.
apparently replies are very limited in length so I'll call this an answer. Thanks for your response. I have actually tried part of this but will try to see if your information gets me any further. After writing this question I explored a little further. I found that the code I had compiled on the ARM and installed still had "x86" and "x86-64" in the domain profile for the device manager and no "armv7l" so I patched the profile and tried starting the device manager on the ARM manually (after setting the omniORB.cfg to point to the name server on the domain manager host. It started up fine and said it was trying to connect, and the name server on the domain manager host now had an entry for the ARM device manager but the IDE did not list the additional device manager and if I killed the ARM device manager it said that it was intrupted while waiting to register so I assume that the device manager registered with the name server but never got a reply from the domain manager. This does not make me hopeful that your steps will work, but I'll give them a try.
Update. Following more closely the steps in sub$100 document, it appears that $SDRROOT/dev/devices/GPP/cpp/devconfig.py did not edit GPP.spd.xml to put in the correct processor and compiler version but after hand editing these, I was able launch the full domain (domainManager, deviceManager, GPPdevice) on the ARM processor and was able to connect to this running domain from the IDE running on x86. After exporting and rebuilding my waveform components and editing their domain profiles I was able to use the IDE to launch successfully a very small three component waveform and control it. So running the entire domain on the ARM works ok.
But I still cannot start the deviceManager on the ARM and have it register with the DomainManager on x86 (after editing the DCD to point to the x86 domain, ie, running a distributed domain with two nodes. It starts and says it is registering with the domainManager, and it must partly succeed because the devMgr shows up in the NamingService under the domain, but the IDE never shows the new deviceManager in the domain. And the devMgr never starts the GPPdevice. If the devMgr is killed it prints "Interrupted waiting to register with DomainManager", so even though it got registered into the Naming Service it appears that the DomainManager never replied to the registration request.
Neaded your help on lirc.
I want to use lirc for decoding of ir signals. I am using a custom board based on Cortex A8 with 2.6.37 kernel and IR is received thru’ serial port. I can see UART interrupts coming properly when I press the button of the IR remote.
But when I try to run the configure script with device=all or device=serial and run make and make install as mentioned in the installation page on lirc.org, It sends me an error that the kernel configuration is invalid.
But still I am able to generate the .ko files(lirc_dev and lirc_serial) needed for loading the kernel modules but not able to insert lirc_serial module as I am using a port having mmio and the port used by lirc is io mapped.
My virtual adddress is 0xfa022000 and physical address is 0x48022000(using ttyO1).
Can I use lirc for this address.
Do I need to make any change in the code?
Also I cannot install directly on the board I am using as I could not build the kernel source code on the board due to minimal things present on the board.So am running the setup on some other machine and cross compiling for arm.
So I could not have the configuration files placed at the right locations also the node(/dev/lirc0) is not made.
Shall I make the node manually or will inserting the modules do the work?
Also do I need to have the configuration files at proper location before inserting the modules?
Also does it have any dependency with the kernel version?
Please suggest me the steps for cross compiling and loading the kernel modules on my own and also let me know which all conf files or other files are required to be present for making the things work.
I would really be very thankful to you for the help.
I have been trying it for the past 2 weeks.
Regards
Harman.
/dev/lirc0 should be created automatically if lirc_serial is loaded successfully. If it's not created, module was not loaded correctly.
lirc_serial does work with mmio - see 'iommap' module's param. You'll need to set it to 1 for mmio to work.
You'll also need to use 'io' and 'irq' params to setup your address and irq.
I'm using UDOO board with Cortex A9 CPU and could get my mmio and irq information from /proc/tty/driver/IMX-uart.
My kernel is newer though - it's 3.0.35 and I'm not sure if all of that will work in your case.
I was eventually able to load lirc_serial, but it still didn't work, so I had to connect my IR receiver directly to GPIO and write my own kernel driver based on lirc_rpi to make it working: http://funny-embeddings.blogspot.com/2013/12/udoo-adding-ir-and-building-lirc-kernel.html