I am developing a code for transmission and reception of a txt file using fec correction and qam modulation. The main problem is in transmission it only send one character or nothing just for a second and then get freeze. It's the first time that i used GNU radio and i don't know what caused this problem can you check the code in the images below and tell me what it could be and how to solve this. If i am doing something wrong please tell me.
Sorry, I don't have the range to post images so instead that I posted links.
This is for TX
Txcode1
Txcode2
This is for RX
RXcode1
RXcode2
You're using an outdated version of GNU Radio, and within that, you're using the explicitly deprecated Packet Encoder, which randomly drops data. Don't do that, you had to pick that block from a category called "Deprecated" for a reason.
Also, it looks like you're using Throttle together with hardware. That doesn't work, and GRC also explicitly tells you it's a bad idea – you should pay attention to the console output in the lower left, it contains useful information!
So, don't start a new project on GNU Radio 3.7; GNU Radio 3.8 or 3.9 is trivial to install from Linux distro sources on any modern Linux Distro, and on Windows, you can use the excellent anaconda installer method.
Afterwards, orient on the examples that come with GNU Radio (installed, typically, under /usr/share/gnuradio/examples) in the digital subfolder. packet_loopback and other files will be good examples to learn from!
Other than that, make sure you've clicked on the "Get Started" button on gnuradio.org, and followed the tutorials up to the point of the PSK transmission tutorial. This should be a good entry to exactly what you're doing.
Related
I wanted to install the OV7251 camera driver to work with a module I've recently purchased, the Arducam OV7251 MIPI, as I need to perform SLAM-like system called Virtual Inertial Navigation (VIN) and global shutter cameras are preferred for this. As far as my system goes, I'm using ROS Kinetic on an RPI-3B+ running Ubuntu 16.04 . I am using this camera as it is near my price point (<20$), and goes through the RPI's CSI Port, which sources say is easier and faster than ones going through USB.
I wanted to take this camera and publish its data to a topic, that way the repository I'm using for VIN, OpenVINS, can track the camera's position. Now, the camera that I'm using doesn't have much on it other than the manufacturer's github page, which does not work on Ubuntu, and cannot connect to ROS. Now, I'm decently inexperienced with RPI's, ROS included, since I wanted to originally perform this on an Arduino, but that was majorly impossible, so I doubt I would be able to write a simple ROS node, let alone one that connected with the CSI port.
Currently, I am unable to find many libraries for this, and help given to me has proved to be un-substantial. The camera does not natively have drivers supported on RPI, which is why I cannot find any /dev/video libraries, cheese turns up nothing, and the command $ Vcgencmd get_camera returns no detected devices. Someone suggested kernel hacking, in order to enable the module in menuconfig using libraries like the ones here. While I do not know much about kernel hacking, he reccomended that I follow this guide and after I run the defconfig line, I should search for "OV7251" in menuconfig and modularize the only one which popped up. And despite flashing and repeating this process multiple times to ensure I did not choose the wrong branch, the rpi-5.4.y branch, or wrong model, the RPI-3B+, I ended up being stuck on the rainbow screen after I rebooted every time. I know that the rainbow screen either means low power, which it wasn't because I had it run before, or a kernel error, which would most likely make sense.
Now, while I would most definitely like to fix the rainbow screen error, I would also like to know, how after installing the OV7251 driver, how do I get it working with ROS to send data to topics? Since I doubt I could write my own node, is there a library that I could look for to perform this, or would libraries that did not work previously due to a missing driver suddenly work now, or would I have to take an existing one and modify it? In any case, A more low-level tutorial to accomplish this would be quite handy seeing as I am new.
But, in the case this is not software, and the reason this camera is not supported is for good reason, is there any other cheap global shutter camera I can work with? I couldn't seem to find many over my various searches, but maybe you all have better luck/experience in this field. Although, I did manage to find another library by this same manufacturer which happens to support my camera model and even has a ROS node that works on ubuntu. However, I believe that if this can be done, then so can doing so by just the CSI port rather than buying an additional 40$ USB camera hat for the pi, and along with that, I am starting to doubt the validity of this companies repositories.
Yet the fact I am finding little information on the topic of this camera alone on the CSI port of an RPI and how renowned this company it scares me that it could be impossible, which if it is, do link me some other good and hopefully well-documented cameras, which could very well be a lot to ask for. And if it is just simply impossible to get the results I want with the parameters I have set, then how badly would a rolling shutter camera affect VIN'S performance, and furthermore is there any special dataset designed for rolling shutter which could minimize the drop in quality? This terrain is all too new to me.
Ok, so I got a rpi engineer to add a dtoverlay for the ov7251 in the rpi's firmware, and the most recent rpi-update has the overlay in the kernel.
I did sudo rpi-update to install the update, i then added dtoverlay=ov7251 to /boot/config.txt in order to enable the overlay, and i edited it by running sudo nano /boot/config.txt. And the repository only has one dependency, v4l-utils, which is installed easily enough by running sudo apt-get install v4l-utils. Finally i ran sudo reboot to initialize the changes.
And in order to pull the images into ROS, i edited a v4l2 node called usb_cam in order to accept the pixel format that the ov7251 camera uses (Y10). My fork can be found here. In order to install it, (since the docs for the original repo say very little on installation), i ran:
cd ~/catkin_ws/src
git clone https://github.com/ai-are-better-than-humans/usb_cam.git
cd ..
catkin_make
and then after that all you have to do is roslaunch usb_cam usb_cam-test.launch to start the node. Mine started out dark, so i had to go into the launch file and mess around with the brightness for a bit. And while youre there, make sure the pixel_format parameter has a value of Y10
You should get a sensor_msgs::Image message being published to a topic named "<camera_name>/image_raw", you can run rqt_graph to visualize it. Big thanks to 6by9 over at raspberry pi forums, dont think i could have gotten it done without him, he did alot of work that im very thankfull for. Thought id share the knowledge back here in case anyone finds it usefull.
EDIT: I hear you can also compile with catkin_make --pkg usb_cam -DCMAKE_BUILD_TYPE=Release instead of catkin_make if the node takes too much CPU. Also, if you see a ton of error messages while compiling, its fine, it still should work, but if you want to get rid of them you can refer to this answer from a ros thread:
It looks like you need to install libavcodec. I don't know the exact
command to install it off the top of my head, but the format will look
like this:
sudo apt-get install libavcodec
The exact package name might not be
libavcodec. It maybe looks something like libavcodec-VERSION-NUMBER or
libavcodec-dev. In these situations you can search for packages with a
command like this:
apt-cache search libavcodec
This will find all packages that have text
containing "libavcodec". This should find the correct package for you
to install.
I need to do some NON-STANDARD signal processing operations with an RFID-reader, so I'd like to know if it is possible to extract antenna's individual analog (actually digital samples right after ADC) input signal samples with Motorola FX7500 (if you know how this works on FX7400 or FX9500, please do tell, could be helpful). Samples would be processed in a JAVA-based host computer program.
What I've already tried:
Investigating Motorola's own RFID3 API's possibilities, it doesn't go deep enough to actually get in touch with input analog signal samples.
Using LLRP to its full extent, it doesn't allow analog signal sample access either. RFsurvey-functionality would have been helpful to some extent, but FX7500 doesn't support it either.
Accessing RFID-reader's linux terminal, trying to find the driver function(s), that could listen the input sample stream. If current input sample(s) could be extracted from the input stream, I could (in theory) make a script, that would save a few of those sample values in a txt-file in the host computer during a tag inventory round. My linux skills are kinda bad, hence I ask this question.
The only realistic way to solution seems to be via linux terminal, so if you folks have any ideas about that (where to look and what to do), please advise!
Contents of reader:
rfidadm#FX7500abcdef:/$ ls -1
apps
bin
dev
etc
home
include
lib
linuxrc
media
mnt
platform
proc
readerconfig
run
sbin
sys
tmp
usr
var
I cannot completely rule that out, but it's highly unlikely you can get the raw signal digitized; the devices you're looking at aren't really software defined radio devices, typically.
"speaking" RFID physically is a bit different from "usual" wireless communication: The reader doesn't only observe the energy transmitted from the tag, but more importantly the fluctuations of energy extracted from the near field of the reader's antenna coil. Hence, you don't actually have a baseband of RF bandpass signal, but hardware-specific modulations of transmitted (and inversely, antenna-reflected) energy. Demodulation is hence usually done in specialized hardware.
However, do not fret: It's totally possible to build a software defined RFID reader. There have been several approaches to that, but personally, I trust these based on Ettus USRPs and/or GNU Radio best. Look through the results IEEExplore gives you, eg. this search.
Most probably this is not possible with the Motorola readers. What you can do, is use one of the RFID chipsets available on the market: either the AMS RFID IC's, or the Impinj RFID IC's. As far as I know, both IC's support retrieving the digital samples that are received. They also have a development kit to test-drive the IC's.
I'm looking into making a project with the Kinect to allow my Grandma to control her TV without being daunted by using the remote. So, I've been looking into basic gesture recognition. The aim will be to say turn the volume of the TV up by sending the right IR code to the TV when the program detects that the right hand is being "waved."
The problem is, no matter where I look, I can't seem to find a Linux based tutorial which shows how to do something as a result of a gesture. One other thing to note is that I don't need to have any GUI apart from the debug window as this will slow my program down a fair bit.
Does anybody know of something somewhere which will allow me to in a loop, constantly check for some hand gesture and when it does, I can control something, without the need of any GUI at all, and on Linux? :/
I'm happy to go for any language but my experience revolves around Python and C.
Any help will be accepted with great appreciation.
Thanks in advance
Matt
In principle, this concept is great, but the amount of features a remote offers is going to be hard to replicate using a number of gestures that an older person can memorize. They will probably be even less incentivized to do this (learning new things sucks) if they already have a solution (remote), even though they really love you. I'm just warning you.
I recommend you use OpenNI and NITE. Note that the current version of OpenNI (2) does not have Kinect support. You need to use OpenNI 1.5.4 and look for the SensorKinect093 driver. There should be some gesture code that works for that (googling OpenNI Gesture yields a ton of results). If you're using something that expects OpenNI 2, be warned that you may have to write some glue code.
The basic control set would be Volume +/-, Channel +/-, Power on/off. But that will be frustrating if she wants to go from Channel 03 to 50.
I don't know how low-level you want to go, but a really, REALLY simple gesture recognize could look at horizontal and vertical swipes of the right hand exceeding a velocity threshold (averaged). Be warned: detected skeletons can get really wonky when people are sitting (that's actually a bit of what my PhD is on).
Is there any documentation on how to write software that uses the framebuffer device in Linux? I've seen a couple simple examples that basically say: "open it, mmap it, write pixels to mapped area." But no comprehensive documentation on how to use the different IOCTLS for it anything. I've seen references to "panning" and other capabilities but "googling it" gives way too many hits of useless information.
Edit:
Is the only documentation from a programming standpoint, not a "User's howto configure your system to use the fb," documentation the code?
You could have a look at fbi's source code, an image viewer which uses the linux framebuffer. You can get it here : http://linux.bytesex.org/fbida/
-- It appears there might not be too many options possible to programming with the fb from user space on a desktop beyond what you mentioned. This might be one reason why some of the docs are so old. Look at this howto for device driver writers and which is referenced from some official linux docs: www.linux-fbdev.org [slash] HOWTO [slash] index.html . It does not reference too many interfaces.. although looking at the linux source tree does offer larger code examples.
-- opentom.org [slash] Hardware_Framebuffer is not for a desktop environment. It reinforces the main methodology, but it does seem to avoid explaining all the ingredients necessary to doing the "fast" double buffer switching it mentions. Another one for a different device and which leaves some key buffering details out is wiki.gp2x.org [slash] wiki [slash] Writing_to_the_framebuffer_device , although it does at least suggest you might be able use fb1 and fb0 to engage double buffering (on this device.. though for desktop, fb1 may not be possible or it may access different hardware), that using volatile keyword might be appropriate, and that we should pay attention to the vsync.
-- asm.sourceforge.net [slash] articles [slash] fb.html assembly language routines that also appear (?) to just do the basics of querying, opening, setting a few basics, mmap, drawing pixel values to storage, and copying over to the fb memory (making sure to use a short stosb loop, I suppose, rather than some longer approach).
-- Beware of 16 bpp comments when googling Linux frame buffer: I used fbgrab and fb2png during an X session to no avail. These each rendered an image that suggested a snapshot of my desktop screen as if the picture of the desktop had been taken using a very bad camera, underwater, and then overexposed in a dark room. The image was completely broken in color, size, and missing much detail (dotted all over with pixel colors that didn't belong). It seems that /proc /sys on the computer I used (new kernel with at most minor modifications.. from a PCLOS derivative) claim that fb0 uses 16 bpp, and most things I googled stated something along those lines, but experiments lead me to a very different conclusion. Besides the results of these two failures from standard frame buffer grab utilities (for the versions held by this distro) that may have assumed 16 bits, I had a different successful test result treating frame buffer pixel data as 32 bits. I created a file from data pulled in via cat /dev/fb0. The file's size ended up being 1920000. I then wrote a small C program to try and manipulate that data (under the assumption it was pixel data in some encoding or other). I nailed it eventually, and the pixel format matched exactly what I had gotten from X when queried (TrueColor RGB 8 bits, no alpha but padded to 32 bits). Notice another clue: my screen resolution of 800x600 times 4 bytes gives 1920000 exactly. The 16 bit approaches I tried initially all produced a similar broken image to fbgrap, so it's not like if I may not have been looking at the right data. [Let me know if you want the code I used to test the data. Basically I just read in the entire fb0 dump and then spit it back out to file, after adding a header "P6\n800 600\n255\n" that creates the suitable ppm file, and while looping over all the pixels manipulating their order or expanding them,.. with the end successful result for me being to drop every 4th byte and switch the first and third in every 4 byte unit. In short, I turned the apparent BGRA fb0 dump into a ppm RGB file. ppm can be viewed with many pic viewers on Linux.]
-- You may want to reconsider the reasons for wanting to program using fb0 (this might also account for why few examples exist). You may not achieve any worthwhile performance gains over X (this was my, if limited, experience) while giving up benefits of using X. This reason might also account for why few code examples exist.
-- Note that DirectFB is not fb. DirectFB has of late gotten more love than the older fb, as it is more focused on the sexier 3d hw accel. If you want to render to a desktop screen as fast as possible without leveraging 3d hardware accel (or even 2d hw accel), then fb might be fine but won't give you anything much that X doesn't give you. X apparently uses fb, and the overhead is likely negligible compared to other costs your program will likely have (don't call X in any tight loop, but instead at the end once you have set up all the pixels for the frame). On the other hand, it can be neat to play around with fb as covered in this comment: Paint Pixels to Screen via Linux FrameBuffer
Check for MPlayer sources.
Under the /libvo directory there are a lot of Video Output plugins used by Mplayer to display multimedia. There you can find the fbdev (vo_fbdev* sources) plugin which uses the Linux frame buffer.
There are a lot of ioctl calls, with the following codes:
FBIOGET_VSCREENINFO
FBIOPUT_VSCREENINFO
FBIOGET_FSCREENINFO
FBIOGETCMAP
FBIOPUTCMAP
FBIOPAN_DISPLAY
It's not like a good documentation, but this is surely a good application implementation.
Look at source code of any of: fbxat,fbida, fbterm, fbtv, directFB library, libxineliboutput-fbe, ppmtofb, xserver-fbdev all are debian packages apps. Just apt-get source from debian libraries. there are many others...
hint: search for framebuffer in package description using your favorite package manager.
ok, even if reading the code is sometimes called "Guru documentation" it can be a bit too much to actually do it.
The source to any splash screen (i.e. during booting) should give you a good start.
BACKGROUND
I am using a commercial application on windows that creates a drawing
This application allows only two output options: (1) save as a bitmap file and (2) print to a printer
the bitmap is useless for my purposes - I want the vectors
Looking at the print output (I sent to the Windows XPS print driver) it seems clear based on the amount of zooming I can do without loss of detail that the underlying vectors are being send to the print driver
Once I get the vectors, I will be writing some code to transform them for some other use.
MY QUESTION
Whart are my options for geting the vectors from the print? (am open to both commercial and open source)
OPTIONS I HAVE THOUGHT OF SO FAR
Take the bitmap and use a program like VectorMagick to. I have tried this approach. It does not produce the fidelity I seek even when the original bitmap is large. Practically speaking I believe that using any tracing approach will not give me the quality vectors I need.
Print to the Adobe PDF driver. This technically works. I have Adobe CS4 so I can print to it save the resulting PDF and then import the PDF into Illustrator and then export as some other vector format. The problem with this approach is money/licensing. I own a personal copy of Adobe CS4 - so this is fine for me. But I need to capture the vectors at work for business purposes - and no I'm not going to install my personal copy of CS4 at work.
Is there a "print driver" that captures the print output directly into a vector format? I have seen some commercial ones via google. If you've used them, I would like to hear about your experience with this technique. I could write my own and in that case do you have links to any existing code that I can start with.
If this is an ongoing solution you need then you might need to buy something or build your own. If it's a onetime affair you might look to use an 'older' Lexmark PCL printer driver. I'd recommend something like the T610. If you download the PCL driver and install it you can modify the defaults and change the Graphics option from XL or Autoselect to GL/2. This will force the driver to output GL/2 output which is vector (GL/2 is a plotter language). This might do the trick for you. Other printer drivers may have the abiltiy to force GL/2 (vs. Raster) but I'm not sure. I use to work for Lexmark and have used this before for a similar requirement.
Ensure you use the Lexmark 'Custom' driver as I don't think the Microsoft-based one support this feature.
...pausing while I investigate a few things............I'm back...
Another option is to find another GL/2 driver or build you own...I just took a few minutes to search the web and came up with a few other options that might work.
Build you own:
I've built drivers (minidrivers) using the Windows Driver Development Kit (DDK), it's quite simple to construct basic drivers. Looks like there is a setting you can set to enable GL/2 output: Enabling HP-GL/2 Vector Graphics Support (PCL-5e) in the GPD
Alternate drivers:
Depending on the OS you are on there is probably a 'generic' GL/2 driver built in. I believe XP has a Hewlett-Packard HP-GL/2 Plotter. You might need to check the license (as with the Lexmark solution) but it might work for you and as it's part of the OS there shouldn't be concern about using it. It's probably written and copyrighted to Microsoft
Keep in mind you will have to do some work to convert GL/2 to whatever output you want but it should be a matter of an simple translator to convert each set of commands. There may be tools out there to help. Here is a quick link to Lexmark GL/2 reference which might be enough to get you going, check out the GL/2 information under the PCL section: Lexmark Technical Reference Guide
Postscript:
The last option I have is to use a generic Postscript driver. Postscript should output the vector images as vector graphics in the Postscript but my knowledge of this is limited at best.
Output:
If you need the output to route to file you can set the port to FILE: which requries user intervention, or install something like Redmon (or connect with me and I'll send you our port monitor that allows for automatic output to file).
Hope this helps in some way.
My favorite is the open source (GPL) PDFCreator
http://sourceforge.net/projects/emfprinter/