I'm trying to play a certain audio file from an SD card using Arduino UNO clone, but I got Error 48 on both of the microSD cards I've tried. Can you please explain to me what does the Error 48 stand for and how to fix it? Thanks
EDIT: I found the meaning in the library files: No valid MBR/FAT-BS signature found in sector 0. I still don't know how to fix it tho :/
No valid MBR/FAT-BS signature found in sector 0.
Related
I tried to provision a device via Bluez and mesh-cfgclient on my Raspberry Pi.
Bluez: 5.65
Raspberry Pi: 3B+
First I am looking for provisionable devices and get:
Scan result:
rssi = -38
UUID = DDDD00000000000000000000000000DD
OOB = 0000
URI Hash = 00000000
If I am stating the provision process with:
provision dddd00000000000000000000000000dd
I get the error:
Failed to generate UUID array from dddd00000000000000000000000000dd
If I am trying this:
provision dddd0000-0000-0000-0000-0000000000dd
I get:
Requires UUID
So I don't know which UUID mesh-cfgclient like to get from me. Do someone know what I missed here.
Thanks for your help.
I'm encountering this as well. I don't know if it's a new issue because this is my first foray into BLE mesh...
My findings so far has led me to the UUID needs to comply with RFC-4122.
This is my conclusion based on downloading the bluez source (specifically 5.65), along with the ell source (specifically 0.55) and walking through add_node_setup, which led me to l_util_from_hexstring, which seemed fine.
It was l_uuid_is_valid that doesn't like the format...
It's expecting the variant (==2) and version (between 1 & 5) to be included.
Mind you, when I mention those values, they are the result of bit-shifting, so variant == 0x80, and version between 0x16 and 0x80, and this is all after the UUID we are provided is converted into hexidecimal.
I haven't done it yet, but you can probably use a uuid generator online or in linux (uuidgen).
I will say that at the moment, I don't know why ell is expecting variant to == 2.
Looking at the RFC, section 4.1.1, I'm not seeing any bit combination that equates to 2.
Actually, looking at the wikipedia for it, I see the UUID number 2 doesn't equate to the bit combination, but rather the zero-based position of the list, which is 110 ("Reserved, Microsoft Corporation backward compatiblity").
If we were to alter your dddd00000000000000000000000000dd, I think it might look like dddd00000000 40 00 80 000000000000dd.
I chose 0x40 for version 4, and 0x80 for the variant #2 mentioned earlier (bit-shifted).
I made an app that discovers Bluetooth devices around me, and I'm looking into the datas I get about them. Now I'm trying to figure out the datas from BluetoothDevice.getBluetoothClass (CoD, Class of Device).
So far I've found these class codes around me:
43c
50c
704
1f00
c043c
c243c
8043c
60680
200408
240414
5a020c
About half of these I found some information for (http://domoticx.com/bluetooth-class-of-device-lijst-cod/). The rest of the codes I haven't been able to find anywhere (50c, c043c, c243c, 60680).
Does anyone know any overview with all of these codes (or at least the ones I haven't figured out)?
You can decode the Bluetooth Class of Device (CoD) yourself by first converting the above hex number to binary (for example using this link) and then checking the document below to try and find what the combination of the bits mean:-
https://www.ampedrftech.com/datasheets/cod_definition.pdf
As an example, 0x50c is 010100001100 in binary. Using the table in the document above, bits 8 to 12 indicate that the device is a peripheral:
And then bits 2 to 5 indicate that the device is a remote control
Let me start off with the components used:
GPIO extension board to connect the raspberry pi to components
Bme280
Pi 3B
Problem description:
This problem was intermittent at first. We were receiving reading and the error occured out of nowhere, made adjustment to the sensor(taking out and putting it back in) which solved it but when we touch the sensor the error showed up again.
We decided to change the sensor and the problem turned from intermittent to persistent. Now we have this as permanent issue.
We removed the package for BME280 and SmBus2 and decided to reinstall it again.
RPI Bme280: https://pypi.org/project/RPi.bme280/
I followed this BME280 installation guide, however when prompting for 'i2cdetect -y 1' there were lines but no number showing up.
What has been confirmed so far:
Patching up of circuits was fine, tested with my lecturer pi and it
works fine.
Codes is fine, we even use the sample code provided by RPi.bme280
I2c was enabled everytime
Please help me because I am really lost. I needa submit this by next week so any help is appreciated.
Problem pic --> Picture of the problem
I've tried to respond, but there is a few pitfalls in SMBus and i2c, so to break the question into smaller bits I've quoted your original message with an indent. The response is provided beneath.
This problem was intermittent at first. We were receiving reading and the error occurred out of nowhere, made adjustment to the sensor(taking out and putting it back in) which solved it but when we touch the sensor the error showed up again.
I locked onto the statement, "Touched the sensor". Is there a chance the BME280 experienced an ESD discharge? And therefore is now partially or fully broken?
Are you using an ESD safe room? or at least ESD bracelet. You will not notice small ESD discharges, and for small electronics even a sub 1000V discharge can cause damage instantly or over time. (Fundamentals of Electrostatic Discarge - incompliancemag.com)
I followed this BME280 installation guide, however when prompting for 'i2cdetect -y 1' there were lines but no number showing up.
The I2Cdetect -y 1
Will send a ReadBit message to each possible slave 0-127. Then listens for the ACK on the slave address.
The message is very simple, but does the trick for detecting working i2c slaves.
As you stated there is no "Lines", i would suggest the slave either has issues responding, if the BME280 has the correct 3v3+GND supplied.
As another possability, could you redo this step dtparam=i2c_arm=on,i2c_baudrate=400000
(Set the baudrate way down to 10000 /10k. Should this solve the issue and you need higher bandwidth, attempt on "50000 /50k" or "100000 /100k") This is just to eliminate the possibility the slave cannot opperate on this high frequency. 400k Baudrate for SMBus is high for a prototype/testing scenario. Very small amounts of interference can corrupt the data over SDA.
Another possibility is the Sink-Current which i've learned the hard way is not the same on i2c and SMBus over i2c.
Is you Pull-up resistor appropriate for the limited sink-current?
The SMBus specifies a minimum sink current of 100µA, and a maximum of 350µA, compared to 3mA for the I²C bus (Ampere=Voltage/Resistance Ohm).
Now to the Software issue.
From your supplied picture on imgur.
File "newcodes_''''''''''''''.py" line 2, in
Your compiler cannot find "bme" where you attempt to import bme280. Reference/path issue?
This can be the cause for other issues further into the code calls.
I don't know what SW you are writing the code in, but if there is an option to insert a breakpoint and run a debug build. I would suggest starting there :)
Alright I have resolved the issue, I changed the wire from jumper wire to hard wire. Thank you guys for your response. I appreciate all of them :D
I'm running a BBB straight out of the box running debian. Kernel version is 3.8.13-bone-47.
I'm working with a cape that is very similar to the one here. The difference is that I'm using a TLV320AIC3106 instead of the AIC3104, and I only have enabled the audio out, I'm not interested in recording audio in this application.
My pinout for my application is identical to the cape in the link above.
I've followed the link here to get the cape up and running. Everything that I have matches the output of the tutorial up until I try and play a sample wave file.
When I play a sample wave file, I get the following message: aplay: pcm_write:1710: write error: Input/output error
Running dmesg gives me ALSA sound/core/pcm_lib.c:1010 playback write error (DMA or IRQ trouble?)
Where I'm having trouble is I don't understand how the DMA is coming in to play. Is this a DMA problem? Is it a symptom of something else going wrong like my I2C? Am I missing a configuration somewhere else?
Any thoughts on how to track this down are appreciated.
I realize it has been covered in multiple places before, but it can never be stressed enough. Make sure that when you're sending out information, make sure it goes to the right address over the I2C. I figured out this morning that the audio codec was at address 0x1B, while the driver was addressed to 0x18. Small but critical difference.
The easy fix is to edit the BB-BONE-AUDI-02-00A0.dts file.
Edit line 65 to <0x1B>. Re-compile using the line: dtc -O dtb -o BB-BONE-AUDI-02-00A0.dtbo -b 0 -# BB-BONE-AUDI-02-00A0.dts
move the generated file to the /lib/firmware directory
Insert it using echo BB-BONE-AUDI-02 > /sys/devices/bone_capemgr*/slots
After applying this simple fix it seems to work. I can't say for certain because I have to get the audio amplifier circuit up and running still. At least aplay will play the file without crashing out on me, which is a start.
Trying to get access to a partially rooted Galaxy S2 external sd card.
The problem is that /dev/block/mmcblk1p1 does not exist on the phone. This is the device name that should allow me to put the "recovery" image onto the sdcard so that the unit will be a phone again.
Problem is, I don't know where to find the magic Major and Minor numbers for this device and I'm trying to figure out where in the kernel source I should be looking for them.
Could someone point me at the right kernel files to find this information?
Standard devices use predefined major numbers and minor numbers starting from 0 for the first instance and upward depending on how many instances there are going to be.
Look at the Linux Documentation file(devices.txt) to see the full list but the section of interest to you is:
179 block MMC block devices
0 = /dev/mmcblk0 First SD/MMC card
1 = /dev/mmcblk0p1 First partition on first MMC card
8 = /dev/mmcblk1 Second SD/MMC card
...
The start of next SD/MMC card can be configured with
CONFIG_MMC_BLOCK_MINORS, or overridden at boot/modprobe
time using the mmcblk.perdev_minors option. That would
bump the offset between each card to be the configured
value instead of the default 8.
So /dev/block/mmcblk1p1 would be major 179, minor 9.
According to hotplug.txt
Entries for block devices are found at the following locations:
/sys/block/*/dev
/sys/block/*/*/dev
So try looking in /sys/block/mmcblk1p1/dev.
EDIT:
Looking at it again I actually think that it will be in /sys/block/mmcblk1/mmcblk1p1/dev