Can you please let me know how to play the wave file for the IMX 51 Multimedia board?The code is copied from the link as shown below:
http://www.qnx.org/developers/docs/6.3.2/neutrino/audio/wavec.html
What are the arguments that needs to be given and where should the wave file be placed on the filesystem.
Advanced thanks
Maddy
The following should work:
wave /full/path/to/wavefile.wav
The same utility is present in your development environment under ${QNX_TARGET}/armle-v7/usr/bin/wave and includes use information:
bash-3.2$ use ./wave
wave Options] *
Options:
-a[card#:]<dev#> the card & device number to play out on
-f<frag_size> requested fragment size
-v verbose
-c<args>[,args ..] voice matrix configuration
-n<num_frags> requested number of fragments
-p<volume in %> volume in percent
-m<mixer name> string name for mixer input
Args:
1=<hw_channel_bitmask> hardware channel bitmask for application voice 1
2=<hw_channel_bitmask> hardware channel bitmask for application voice 2
3=<hw_channel_bitmask> hardware channel bitmask for application voice 3
4=<hw_channel_bitmask> hardware channel bitmask for application voice 4
(The above output was captured on 650 SP1.)
Related
I'm trying to learn how to use BLE on a Pi4.
I have installed hcitool and gatttool and have figured out how to use them. I have also set up a virtual device using LightBlue on a Mac.
pi#raspsky:~ $ sudo hcitool -i hci0 lescan
LE Scan ...
98:9E:63:39:8B:ED Blank
98:9E:63:39:8B:ED (unknown)
That "Blank" is the virtual device.
pi#raspsky:~ $ gatttool -b 98:9E:63:39:8B:ED -I
[98:9E:63:39:8B:ED][LE]> connect
Attempting to connect to 98:9E:63:39:8B:ED
Connection successful
[98:9E:63:39:8B:ED][LE]> primary
attr handle: 0x0001, end grp handle: 0x0005 uuid: 00001800-0000-1000-8000-00805f9b34fb
<snip>
attr handle: 0x0028, end grp handle: 0x002b uuid: 00001111-0000-1000-8000-00805f9b34fb
[98:9E:63:39:8B:ED][LE]> char-desc
handle: 0x0001, uuid: 00002800-0000-1000-8000-00805f9b34fb
<snip>
handle: 0x002b, uuid: 00002901-0000-1000-8000-00805f9b34fb
Now, I'd like to be able to read from the virtual device, but I have no idea which "handle" to use. I figured out by trial and error that I need to use 002b:
[98:9E:63:39:8B:ED][LE]> char-read-hnd 002b
Characteristic value/descriptor: 53 6f 6d 65 74 68 69 6e 67
That hex turns out to be the ascii string "Something" which is what I put in the virtual device.
But, where does that handle come from? It seems like I ought to be able to figure it out without having to use trial and error:
UPDATE:
In this example Using bash and gatttool to get readings from Xiaomi Mijia LYWSD03MMC Temperature Humidity sensor, the author shows how to use hcitool to get the mac address of a BLE Device. The article then goes on with an example:
bt=$(timeout 15 gatttool -b A4:C1:38:8C:77:CA --char-write-req --handle='0x0038' --value="0100" --listen)
But the author never explains where the handle (handle='0x0038') came from. I see how you can get a list of handles using gatttool, but the only way I can figure out what data goes with each handle is to try each one until I find the one I want. There must be an easier way.
Since you updated your question, I have another answer for you. But since your topic is not facing any programming issue, you better ask it again at another StackExchange.
the only way I can figure out what data goes with each handle is to try each one until I find the one I want. There must be an easier way.
I guess I have to disappoint you here.
While there are some predefined GATT profiles by Bluetooth SIG, most of the proprietary implementations do not expose any meaningful information about their characteristics but the mandatory UUIDs.
If you are lucky, you might be able to find a Characteristic User Description (Bluetooth Core Spec Vol. 3 Part G 3.3.3.2) or deduce some information from a Characteristic Presentation Format (Bluetooth Core Spec Vol. 3 Part G 3.3.3.5) characteristic descriptor; but since these are optional, I doubt that a proprietary implementation will provide these.
So for a proprietary implementation, you have to reverse engineer that information or try to find it online (often other people already reversed engineered common devices).
hcitool, and gatttool were deprecated by the BlueZ project in 2017. If you are following a tutorial that uses them, there is a chance that it might be out of date. The current BlueZ tool for generic scanning and exploration is bluetoothctl.
With BLE the UUID is the key to identifying the service/characteristic/descriptor that you are interested in.
The 16-bit UUID Numbers Document lists the adopted UUIDs. SIG-adopted attribute types (UUIDs) share all but 16 bits of a special 128-bit base UUID:0000xxxx-0000-1000-8000-00805F9B34FB. The document lists the 16-bit value that goes into that base.
As you have with the virtual device using LightBlue, custom UUIDs can be created. These need to be outside of the 128-bit base reserved for SIG-adopted values.
As SO is about software development, I'll point you at the BlueZ API documentation should you want to do any of this with code. There are also examples in the BlueZ source tree.
The thing you are looking for is generally speaking GATT/ATT itself.
Basically you query a device implementing a GATT server
The best (res)source and reference for anything related to Bluetooth® is IMHO the Bluetooth Core Specification in the version your devices support and you are developing for.
Attribute Protocol (ATT)
Bluetooth Core Specification 5.2 Vol. 3 Part F describes the ATTRIBUTE PROTOCOL (ATT) as follows:
This Part defines the Attribute protocol; a protocol for discovering, reading, and writing attributes on a peer device
The ATT is some sort of "low level" since it describe the actual protocol itself and its messages / Protocol Data Units (PDUs), but it's definitely worth a (periphere) read, especial chapters 3.1 Introduction and 3.2 Basic Concepts.
Generic Attribute Profile (GATT)
Bluetooth Core Specification 5.2 Vol. 3 Part G describes the GENERIC ATTRIBUTE PROFILE (GATT) as follows:
This Part defines the Generic Attribute Profile that describes a service framework using the Attribute protocol for discovering services, and for reading and writing characteristic values on a peer device.
You can think of GATT like a high-level API for issuing ATT queries and commands.
You should definitely give the complete chapter 2.6 GATT Profile Hierarchy a read and then head over to 4 GATT Feature Requirements, especially chapters 4.4 Primary Service Discovery, 4.6 Charateristic discovery and *4.7 Characteristic Descriptor Discovery - regarding your question
But, where does that handle come from?
On a test server there are two Samsung 960 Pro SSDs, exactly same maker, model and size. On both I've installed a fresh install of exactly the same OS, OmniOS r15026.
By pressing F8 at POST time, I can access the motherboard BOOT manager, and choose one of the two boot drives. Thus, I know which one the system booted from.
But how can one know programmatically, after boot, which is the boot disk?
It seems that is:
Not possible on Linux,
Not possible on FreeBsd
Possible on macOS.
Does Solaris/illumos offer some introspective hooks to determine which is the boot disk?
Is it possible to programmatically determine which is the boot disk on Solaris/illumos?
A command line tool would be fine too.
Edit 1: Thanks to #andrew-henle, I have come to know command eeprom.
As expected it is available on illumos, but on test server with OmniOS unfortunately it doesn't return much:
root#omnios:~# eeprom
keyboard-layout=US-English
ata-dma-enabled=1
atapi-cd-dma-enabled=1
ttyd-rts-dtr-off=false
ttyd-ignore-cd=true
ttyc-rts-dtr-off=false
ttyc-ignore-cd=true
ttyb-rts-dtr-off=false
ttyb-ignore-cd=true
ttya-rts-dtr-off=false
ttya-ignore-cd=true
ttyd-mode=9600,8,n,1,-
ttyc-mode=9600,8,n,1,-
ttyb-mode=9600,8,n,1,-
ttya-mode=9600,8,n,1,-
lba-access-ok=1
root#omnios:~# eeprom boot-device
boot-device: data not available.
Solution on OmniOS r15026
Thanks to #abarczyk I was able to determine the correct boot disk.
I had to use a slightly different syntax:
root#omnios:~# /usr/sbin/prtconf -v | ggrep -1 bootpath
value='unix'
name='bootpath' type=string items=1
value='/pci#38,0/pci1022,1453#1,1/pci144d,a801#0/blkdev#w0025385971B16535,0:b
With /usr/sbin/format, I was able to see entry corresponds to
16. c1t0025385971B16535d0 <Samsung-SSD 960 PRO 512GB-2B6QCXP7-476.94GB>
/pci#38,0/pci1022,1453#1,1/pci144d,a801#0/blkdev#w0025385971B16535,0
which is correct, as that is the disk I manually selected in BIOS.
Thank you very much to #abarczyk and #andrew-henle to consider this and offer instructive help.
The best way to find the device from which the systems is booted is to check prtconf -vp output:
# /usr/sbin/prtconf -vp | grep bootpath
bootpath: '/pci#0,600000/pci#0/scsi#1/disk#0,0:a'
On my Solaris 11.4 Beta system, there is a very useful command called devprop which helps answer your question:
$ devprop -s bootpath
/pci#0,0/pci1849,8c02#1f,2/disk#1,0:b
then you just have to look through the output of format to see what that translates to. On my system, that is
9. c2t1d0 <ATA-ST1000DM003-1CH1-CC47-931.51GB>
/pci#0,0/pci1849,8c02#1f,2/disk#1,0
Use the eeprom command.
Per the eeprom man page:
Description
eeprom displays or changes the values of parameters in the EEPROM.
It processes parameters in the order given. When processing a
parameter accompanied by a value, eeprom makes the indicated
alteration to the EEPROM; otherwise, it displays the parameter's
value. When given no parameter specifiers, eeprom displays the values
of all EEPROM parameters. A '−' (hyphen) flag specifies that
parameters and values are to be read from the standard input (one
parameter or parameter=value per line).
Only the super-user may alter the EEPROM contents.
eeprom verifies the EEPROM checksums and complains if they are
incorrect.
platform-name is the name of the platform implementation and can be
found using the –i option of uname(1).
SPARC
SPARC based systems implement firmware password protection with
eeprom, using the security-mode, security-password and
security-#badlogins properties.
x86
EEPROM storage is simulated using a file residing in the
platform-specific boot area. The /boot/solaris/bootenv.rc file
simulates EEPROM storage.
Because x86 based systems typically implement password protection in
the system BIOS, there is no support for password protection in the
eeprom program. While it is possible to set the security-mode,
security-password and security-#badlogins properties on x86 based
systems, these properties have no special meaning or behavior on x86
based systems.
I have:
USB Sound which is alsa "Device" or "hw:1,0"
Asterisk console configured to use "plughw:1,0"
This works, letting me use the USB Sound for making and receiving voice calls via Asterisk.
I also want to use multimon to decode DTMF tones during the call. If I stop Asterisk I can run "aoss multimon -T DTMF" to decode the tones successfully but in order to do so I had to create an /etc/asoundrc file like so:
pcm.dsp0 { type plug slave.pcm "hw:1,0" }
Starting Asterisk, which grabs the "plughw:1,0" means I get an error trying to run multimon. I believe this is because only one app can access an alsa device at any one time.
I think I need to split the hw:1,0 into two new alsa devices, which I have been trying to do using alsa plugins (dmix/multi) but I'm afraid I can't get my head around how to get these configured!
p.s. I want to use multimon as I also have other use cases for using it on the same setup to decode other tones than just DTMF.
As #CL have pointed, you could use dsnoop for analysing the audio trhough multimon. The following extract has been taken from Basic Virtual PCM Devices for Playback/Capture, ALSA | nairobi-embedded
The dmix[:$CARD...] and dsnoop[:$CARD...] Virtual PCM Devices
A limitation with the hw[:$CARD...] and plughw[$CARD...] virtual PCM devices (on systems with no hardware mixing) is that only one application at a time can access an audio stream. The dmix[:$CARD...] (playback) and dsnoop[:$CARD...] (capture) virtual PCM devices allow mixing or sharing, respectively, of a single stream among several applications without the intervention of a sound server, i.e. these devices use native ALSA library based mechanisms.
We have "Interactive Voice Response (IVR)" set-up using asterisk PBX that interacts with callers, gathers information and routes calls to the appropriate recipient.
We have used Playback function in asterisk to play the IVR but the issue is that when we play the audio file, the volume is very low i.e it is not audible.
We have used the on-line tool "http://www.text2speech.org/" which help us to increase the intensity of the volume but asterisk needs a file with only "8 K Hz" sampling rate which decrease the volume intensity and again it is not audible.
Is there any tool specific for "8000 K Hz" audio file generation with high intensity volume that it should be visible clearly audible. Please help us in any other technique.
Thanks in advance.
Use SoX It's one of the best tool for sound along with ffmpeg.
I don't know your platform but here is a windows command:
sox.exe "input" -r 8000 -c 1 -t ul -w "output"
Asterisk works better with ulaw files, the command above will give you a frequency of 8000kHz.
There is 2 options
1) Change file to be louder. You can use sox or audacity(free editor for windows)
2) Change in dialplan volume using VOLUME function
Just any old GSM compatible SIM card (bonus for 3G USIM).
I presume I need some hardware? Can anyone recommend something cheap for hobbyist, and something more professional?
I presume that there will be full docs of an API with the h/w, so maybe this should be tagged "no-programming-related"? Sorry, if so.
Any good URLs or books (I am conversant with the 3GPP standards).
I'm not (black hat) hacking, don't worry, just not pleased with the likes of SIM Card Secretary, Data Doctor Recovery, etc, so would like to code my own, but might turn it commercial, or offer SIM card programming services (data recover from damaged card, etc) as a sideline.
Update: while I am primarily interested just reading my SMS for backup, it might be a bonus if someone knows of a cheap SIM card writer (so that I can back up all or part of the SIM and restore it later)
You can do that with any PC/SC smart card reader (and writer, as others pointed out) and a program that can read and parse the data for you.
Talking to a card is done via APDU commands (defined in ISO-7816)
The command set used by SIM (2G) and USIM (3G) cards is different, so you have to keep that in mind
The structure and format of the file system of a SIM card is defined in GSM 11.11 (for 2G) and ETSI TS 131.102 (for 3G) - all this documentation is public and available free of charge
The SMS are kept in a file called EF SMS, its name is 0x6F3C, its structure is defined in section 10.5.3 of GSM 11.11
Direct answers to your questions:
Here's where to buy a SIM reader, click on 'photos' to see pics of the device and screenshots of the software
SIM Manager is the program that does everything you want (including reading SMS, restoring SMS, it can even attempt to recover deleted SMS - if they're still physically on the card)
A SIM card SDK is available too. It is a DLL you can load and apply in your program. This thing does all the hard work for you, all you need is to create a GUI on top of it
I am one of the people from the team that created SIM Manager and the aforementioned SDK.
You'll certainly need a smartcard reader and from what I've been able to find out, pretty much any one will do because they all have to support the standard functionality. They also happen to be pretty cheap. Mine is an OmniKey (not sure what model because I don't have it here right now).
Presuming that you're developing under Windows, the Windows API has functions that make it possible to access smartcards. Here is an article on CodeProject that discussees this in greater detail as part of a set of several C# classes that give you access to a bunch of this stuff without having to tangle with the nuts and bolts. I think that the guy's example app is specifically for SIM cards, so that'll probably help.
There's lots of products and hardware to read and write SIM cards, have a look at http://forum.gsmhosting.com/vbb/f500/ in this forum you will find plenty of info concerning sim cards, mobile phones.. one of the bigest resource since 1999!
for hardware programmers, you can build your own like JDM or ICprog.. check kiscan.net for some info..
You can use simLAB tool for reading and editing almost any SIM file.
It works with every PC/SC smartcard reader. The tool also allows you to backup SIM file system.
Have a look at https://github.com/kamwar/simLAB
pySim
In the below example, we are changing the card’s IMSI to
901700000003080 (option -i) and we are specifying a new set of -n NAME
(Operator name), -t TYPE (Card type), -c CC (Country code), -x MCC
(Mobile Country Code), -y MNC (Mobile Network Code) and -s ID
(Integrated Circuit Card ID) values.
$ ./pySim-prog.py -p 0 -n OpenBSC -t sysmosim-gr1 -i 901700000003080 -c 001 -x 001 -y 02 -s 1791198229180000075
Is it enough just filling the new SIM card with new meta and will it working the same way as original? pyusb
Here is the full list of options:
$ ./pySim-prog.py -help
Usage: pySim-prog.py [options] Options:
-h, --help show this help message and exit
-d DEV, --device=DEV Serial Device for SIM access [default: /dev/ttyUSB0]
-b BAUD, --baud=BAUD Baudrate used for SIM access [default: 9600]
-p PCSC, --pcsc-device=PCSC
Which PC/SC reader number for SIM access
-t TYPE, --type=TYPE Card type (user -t list to view) [default: auto]
-a PIN_ADM, --pin-adm=PIN_ADM
ADM PIN used for provisioning (overwrites default)
-e, --erase Erase beforehand [default: False]
-S SOURCE, --source=SOURCE
Data Source[default: cmdline]
-n NAME, --name=NAME Operator name [default: Magic]
-c CC, --country=CC Country code [default: 1]
-x MCC, --mcc=MCC Mobile Country Code [default: 901]
-y MNC, --mnc=MNC Mobile Network Code [default: 55]
-m SMSC, --smsc=SMSC SMSP [default: '00 + country code + 5555']
-M SMSP, --smsp=SMSP Raw SMSP content in hex [default: auto from SMSC]
-s ID, --iccid=ID Integrated Circuit Card ID
-i IMSI, --imsi=IMSI International Mobile Subscriber Identity
-k KI, --ki=KI Ki (default is to randomize)
-o OPC, --opc=OPC OPC (default is to randomize)
--op=OP Set OP to derive OPC from OP and KI
--acc=ACC Set ACC bits (Access Control Code). not all card types are supported
-z STR, --secret=STR Secret used for ICCID/IMSI autogen
-j NUM, --num=NUM Card # used for ICCID/IMSI autogen
--batch Enable batch mode [default: False]
--batch-state=FILE Optional batch state file
--read-csv=FILE Read parameters from CSV file rather than command line
--write-csv=FILE Append generated parameters in CSV file
--write-hlr=FILE Append generated parameters to OpenBSC HLR sqlite3
--dry-run Perform a 'dry run', don't actually program the card
The source code is available.
Also the SIM card is just a smart card. You can use pyscard or pyusb to operate on it. I found this Q&A helpful.