I am using the instructions of https://pimylifeup.com/raspberry-pi-rfid-rc522/ to learn how to read my rfid-rc522.
I installed all the things needed, and cloned from git all the files. I connected accordingly and double checked the wire.
The code in Write.py is
#!/usr/bin/env python
import RPi.GPIO as GPIO
import SimpleMFRC522
reader = SimpleMFRC522.SimpleMFRC522()
try:
text = raw_input('New data:')
print("Now place your tag to write")
reader.write(text)
print("Written")
finally:
GPIO.cleanup()
When I run it- The result stops after "Now place your tag to write" and nothing happens when I place my tag. Any help please? What's wrong here? The module gives red light meaning it is connected. Is it really connected? How do I know? Please help.
Edit: My title and tags were wrong in this question due to already saved data. I edited. :)
It can be multiple reasons why your reader is not retrieving any data:
The RFID cards that you are providing to the reader are not supported by the ISO 14443: Mifare Classic, 4K. (Some DesFire, etc...) are the cards you want to try. Source: https://en.wikipedia.org/wiki/ISO/IEC_14443
The MFRC522 is not receiving enough input voltage. Try to increase from 3.3V to 4V. I have tried with 5V months and the reader is still running perfectly, but be cautious. The safe range in NXP is from 2.5V to 3.6V. Source: https://www.nxp.com/docs/en/data-sheet/MFRC522.pdf
The library you are using does not support IRQ (Interruption Request). This means the process of reading UIDs is high CPU consuming and low in performance. Try to use this popular library which supports interruptions: https://github.com/ondryaso/pi-rc522 . You will need to connect another wire from the IRQ pin in the MFRC522 to one GPIO pin in the Raspberry that is free and supports reading/writing operations.
Check if SPI interfaces are enable in Raspbian. Open a terminal and run:
ls -l /dev/spi
Lastly, it could be that your reader is broken. Some chinese versions do not work as they should do. Maybe you should buy another one and try more luck.
I suppose you have connected all cables in the correct way between the MFRC522 and the Raspberry Pi. Check that again.
I bought a HM-15 BLE bluetooth module and successefully connected to Arduino. I am able to sent At commands and I would like to use it for scanning for iBeacons and get their major and minor.
Using AT+DISC? I can see the beacon address but I cannot connect to it and now I am stuck on how to retrieve major and minor
Can you help me? Here is the datasheet of the module:
http://www.elecrow.com/download/bluetooth40_en.pdf
Thanks
Bluetooth beacons do not require a connection and you read the identifiers directly from the advertisement.
Read section 19, Start a discovery scan, and learn how to read and decode the bytes in the discovered peripherals. The exact byte layout varies for different beacon types. For AltBeacon, an open source beacon variant, you can see the byte layout here: https://github.com/AltBeacon/spec
To decode a proprietary beacon format, you will need to learn how that beacon layout differs from the example linked above.
Old question, but just for the record, you can use AT-DISI?
This will scan for beacons, including iBeacons and also AltBeacons. The response from HM-10 will include RSSI for each.
PS: I'm assuming HM-15 and HM-10 operate the same way. Probably not exactly a fully reasonable assumption.
Does anyone know of a good way to get a bi-directional dump of MIDI SysEx data on Linux? (between a Yamaha PSR-E413 MIDI keyboard and a copy of the Yamaha MusicSoft Downloader running in Wine)
I'd like to reverse-engineer the protocol used to copy MIDI files to and from my keyboard's internal memory and, to do that, I need to do some recording of valid exchanges between the two.
The utility does work in Wine (with a little nudging) but I don't want to have to rely on a cheap, un-scriptable app in Wine when I could be using a FUSE filesystem.
Here's the current state of things:
My keyboard connects to my PC via a built-in USB-MIDI bridge. USB dumpers/snoopers are a possibility, but I'd prefer to avoid them if possible. I don't want to have to decode yet another layer of protocol encoding before I even get started.
I run only Linux. However, if there really is no other option than a Windows-based dumper/snooper, I can try getting the USB 1.1 pass-through working on my WinXP VirtualBox VM.
I run bare ALSA for my audio system with dmix for waveform audio mixing.
If a sound server is necessary, I'm willing to experiment with JACK.
No PulseAudio please. It took long enough to excise it from my system.
If the process involves ALSA MIDI routing:
a virtual pass-through device I can select from inside the Downloader is preferred because it often only appears in an ALSA patch bay GUI like patchage an instant before it starts communicating with the keyboard.
Neither KMIDIMon nor GMIDIMonitor support snooping bi-directionally as far as I can tell.
virmidi isn't relevant and I haven't managed to get snd-seq-dummy working.
I I suppose I could patch ALSA to get dumps if I really must, but it's really an option of last resort.
The vast majority of my programming experience is in Python, PHP, Javascript, and shell script.
I have almost no experience programming in C.
I've never even seen a glimpse of kernel-mode code.
I'd prefer to keep my system stable and my uptime high.
This question has been unanswered for some time and while I do not have an exact answer to your problem I maybe have something that can push you in the right direction (or maybe others with similar problems).
I had a similar albeit less complex problem when I wanted to sniff the data used to set and read presets on an Akai LPK25 MIDI keyboard. Similar to your setup the software to setup the keyboard can run in Wine but I also had no luck in finding a sniffer setup for Linux.
For the lack of an existing solution I rolled my own using ALSA MIDI routing over virmidi ports. I understand why you see them as useless because without additional software they cannot help at sniffing MIDI traffic.
My solution was programming a MIDI relay/bridge in Java where I read input from a virmidi port, display the data and send it further to the keyboard. The answer from the keyboard (if any) is also read, displayed and finally transmitted back to the virmidi port. The application in Wine can be setup to use the virmidi port for communication and in theory this process is completely transparent (except for potential latency issues). The application is written in a generic way and not hardcoded to my problem.
I was only dealing with SysEx messages of about 20 bytes length so I am not sure how well the software works for sniffing the transfer of large amounts of data. But maybe you can modify it / write your own program following the example.
Sources available here: https://github.com/hiben/MIDISpy
(Java 1.6, ant build file included, source is under BSD license)
I like using aseqdump for that.
http://www.linuxcommand.org/man_pages/aseqdump1.html
You could use virtual midi devices for this purpose. So you have to load snd_seq_dummy so that it creates at least two ports:
$ sudo modprobe -r snd_seq_dummy
$ sudo modprobe snd_seq_dummy ports=1 duplex=1
Then you should have a device named Midi through:
$ aconnect -i -o -l
client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0:A'
1 'Midi Through Port-0:B'
client 131: 'VMPK Input' [type=user,pid=50369]
0 'in '
client 132: 'VMPK Output' [type=user,pid=50369]
0 'out '
I will take the port and device numbers form this example. You have to inspect them yourself according to your setup.
Now you plug your favourate MIDI Device to the Midi Through ports:
$ aconnect 132:0 14:0
$ aconnect 14:0 131:0
At this time you have a connection where you can spy on both devices at the same time. You could use aseqdump to spy the MIDI conversation. There are different possibilities. I suggest to spy the connection between the loopback devices and the real device. This allows you for rawmidi connections to the loopback devices.
$ aseqdump -p 14:0,132:0 | tee dump.log
Now everything is set up for use. You just have to be careful about port names in your MIDI application. It should read MIDI data from Midi Through Port-0:B and write data to Midi Through Port-0:B.
Some additional hint: You could use the graphical frontend patchage for connecting and inspecting the MIDI connections via drag and drop. If you do this you will see that every Midi Through port occurs twice once as input and once as output. Both have to be connected in order to make this setup work.
If you want to use GMidiMonitor or some other application you spy on both streams intermixed (without showing the direction) using aconnect suppose 129:0 is the Midi Monitor port :
$ aconnect 14:0 129:0
$ aconnect 132:0 129:0
If you want to have exact direction information you could add another GMidiMonitor instance that you connect only to one of the ports. The missing messages come from the other port.
What about using gmidimonitor? See http://home.gna.org/gmidimonitor/
I have a telephony modem which gives voice to my interfaced application via a serial USB ttyUSB0 in 16bit PCM 8000hz. I am able to capture this data and play with audacity. I want this port to be detected as a sound device in linux (I am on ubuntu). Is it possible? Are there any other options?
I'm guessing you are using a huawei 3G modem or something similar which gives ttyUSB1 for audio. Make sure you have the serial driver binded to it. Then simply pass the port itself as a "file" for input for any program of your choice.You need root access for that.You figured out the audio settings so it must be enough.I have voice calling working in UBUNTU 11.10 with Huawei. So let me know if i can help any further.
Ok, I see it's very old question but answers helped me to get a right direction so I decided to help others.
The one way to achieve (in addition to below) what are you are
looking for is to write dynamic kernel module.
Have it register as a sound device, and check that it has a GSM
module present (which module is it exactly can be recognized in
dmesg, lsmod, or output).
Then establish communication between user space representation as a
sound card and serial usb module.
The other way is to get module that you recognized by dmesg, lsmod and extend its functionality as a sound card.
All are tricky tasks because:
in the first case you have to resolve intermodule communication at the kernel level...... which is, lets say, a little hard even if programmer has a right background in subject.
the second case is hard in that you have to deal with:
USB stack (which is little unpleasant for human beings) and
sound subsystem (which is a little burdensome because of historical issues).
Without being an experienced kernel programmer there are small chances to succeed.
I'm creating a very simple application to read the info from a GPS. The information is sent on the bluetooth (COM3) in the NMEA0183 format.
Everything works good except that I can't find my position because the RMC and GGA sentence are empty. I receive other sentence with the satellite informations and positioning, but all I want is my current position (long/lat)
Here is some example of what I currently receive:
$GPZDA,,,,,,*48
$GPGGA,,,,,,,,,,,,,,*56
$GPGLL,,,,,,,*7C
$GPRMC,,,,,,,,,,,*67
$GPGST,,,,,,,,,,,,,,*57
$GPGSA,M,3,09,18,22,14,,,,,,,,,12.2,11.8,3.0*31
$GPGRS,,,,,,,,,,,,,,*51
$GPVTG,30.124,T,30.124,M,0.067,N,0.125,K*49
$GPGSV,2,1,08,22,78,283,50,18,60,137,50,14,54,281,48,09,44,052,48*7F
$GPGSV,2,2,08,46,34,212,,51,28,222,,48,12,247,,35,06,254,*74
I tried with Putty, GPS .NET 3.0.2 and my own program and the result is the same. BUT when I connect with the proprietary software called eZField, the GPS gets a fix after 20 seconds and I can see the long/lat showing. In EZField, I can't see the raw format and since it is on a pocket PC, I don't know how to sniff the bluetooth data to see if the software send any information to the GPS.
My best guest is that EZField sends some information to the GPS receiver to tell him to start sending RMC and GGA. I've read somewhere that there are "Initialization strings" that can be sent to a GPS but I can't find information about this anywhere. My GPS is a ViaSAT L1-GPS Receiver/SBAS.
Anyone can help me? :)
Thank!
It looks like your GPS doesn't have a fix yet. It is odd though that the GPS doesn't simply start searching on its own. Most initilization strings are strictly for what type of data to send back (such as the SiRFstar III proprietary format).
Pair this to your PC and run the software on it after you have started up some serial port monitoring software. That way, you can see what the init. string is, if there is one.
I use this regularly: http://www.serial-port-monitor.com/