A trying to read selec mfm384 c energy meter using modbus RTU protocol in terminal software (Docklight), am getting some irrelevant response starting with 3F...... it need to respond with Slave address in its first byte, how ever CRC is also getting failed,Can you help me in explaining command and response formats in selec mfm 384
Solved : I have 2 Wire RS 485 from energy meter and i have always (Even while energy meter is responding through Rx+ and Rx- lines )enabled Tx+ and Tx- , Which caused corruption of transmitted data from energy meter
Related
My APB1 clock is reported by the STM32 library as being 36MHz.
I used a website to calculate a prescaler value of 3 (4 with the automatic +1), BS1 of CAN_BS1_15tq and BS2 of CAN_BS2_2tq. When I use the values in a quick spreadsheet calculation they come out right for a 500 Kbit/s baud rate.
I used different values, but assuming the same clock speed of 36 MHz to talk at 250 Kbit/s baud rate to NMEA 2000 devices successfully. When I run my code at 250 Kbit/s it works correctly and talks to my test board (which is using the same code) successfully.
I wondered if the TX and RX pin GPIO speed mattered. Here is my configuration for those pins:
gpio_init_data.GPIO_Speed = GPIO_Speed_10MHz;
gpio_init_data.GPIO_Pin = CAN1_RX;
gpio_init_data.GPIO_Mode = GPIO_Mode_IPU;
GPIO_Init(CAN1_PIN_GROUP, &gpio_init_data);
gpio_init_data.GPIO_Pin = CAN1_TX;
gpio_init_data.GPIO_Mode = GPIO_Mode_AF_PP;
GPIO_Init(CAN1_PIN_GROUP, &gpio_init_data);
When I run at 500 KBit/s baud rate I get all transmissions failing and arbitration lost flagged: TSR=41000004. This happens even with the RX and TX pins at GPIO speed 50 MHz.
The CAN transceiver is an ISO1050 which, according to the data sheet, can handle up to 1 Mbit/s.
Does anyone have any idea what I could be doing wrong? Could it be a problem in the circuitry?
As Lundin said, "CAN transceivers need an ideal impedance of 60 ohm to work properly."
The system I am using is a test rig with a board to be tested connected to a test board by about 8cm of CAN bus cable pair. Up to speeds of 250 Kbits this works perfectly well, but not at 500 Kbits.
Adding a 56 ohm resistor (2 x 120 ohm may be better) solves the problem.
Many thanks to Lundin for his patience and excellent information.
I am trying to use STM32f407 to receive a char from Rpi4.
And I use the function-HAL_UART_Receive_IT() to receive data transmitted from Rpi4, while my Rpi4 use the function included from <wiringSerial.h>, serialPutchar().
However, when I deliver 48 in decimal ('0' in ascii code) from Rpi4, the data received in my STM32 is 252 in decimal.
Could someone tell me how to solve it?
Thank you all very much!
Double check serial configuration on both sides (Polarity, bitrate, stopbit, parity... etc), if this is not enough check the trasmission with a scope and verify that what's on the line correspond to expected settings.
You might want to check the clock configuration of stm32. I've encountered a similar situation that I set the wrong clock frequency.
The SYSCLK should be 168 MHz, and the APB1 frequency should be 42 MHz.
I'm implementing a virtual instrument on STM32 (STM32F103x). Like a normal "hello world", I tried to start with the simplest MIDI message, sending NOTE-ON MIDI message in a loop to see if it works.
I send MIDI NOTE-ON message for every 500ms, only NOTE-ON message in a forever loop, but it not works. Is there any other MIDI message must be sent to make MIDI works? Like some initialize message?
Based on MIDI 1.0 spec, I finish my code on STM32 by sending MIDI message via USART interface.
Then use a logical analyzer, I confirmed my MIDI message is fully match the MIDI 1.0 spec. At least I believe it correct, no issue. 31250 baud rate, 1 start bit, 1 stop bit, one status message 0x92 followed by two data bytes 0x48 and 0x7F, LSB first.
Below is the NOTE-ON message captured by the logical analyzer on TX line of URAT interface. I continue send the same 3 bytes for every 500ms.
The totally time for those 3 bytes are 960 microseconds also match MIDI 1.0 spec mentioned value.
Then, based on "(CA-033) MIDI 1.0 Electrical Specification Update [2014]", I buy one 5 PIN MIDI OUT jack, connect the URAT TX line to PIN-5 through a 10 Ohm resister, connect 3.3V power to Pin-4 through a 33 Ohm resister, PIN-2 and Jack shield connect to GND. Other optional parts (buffer for Rc, ferrite beads) are not used.
However, when I use a USB-MIDI wire connect my MIDI OUT jack to my PC, nothing happen. The USB-MIDI wire has two LED indicators , one for power another for MIDI signal. After connect, the power LED is light, but the MIDI signal LED never light.
I tried to use logical analyzer to analysis PIN-5 of my MIDI OUT jack, the MIDI message byte are totally same with URAT TX line, and every 500ms one NOTE-ON message. However, it never works.
I also tried to create my own PCB with Dream SAM2695 by follow the SAM2695 Evaluation Boards. Then connect the URAT TX directly to MIDI_IN pin of SAM2695, it still no response. Since I have no confidence on my manual soldering PCB, not sure if the PCB itself has issue cause it no response. So I buy a USB-MIDI wire, but the result as I mentioned above, still no response.
======= Apr.26.2021 Update =========
Based on comments, have tried to check the output of the optocoupler.
Before do this check, I bought several BSS138 to transform the MIDI signal to 5V single use below circuit (of course change the resisters near MIDI JACK pin to 220 Ohm as the spec)
After this change I measured voltage of the 5V URAT TX, it show as 4.8+ V, and Logical Analyzer show correct MIDI note on message of this new 5V MIDI signal. However, it still not works.
The only left troubleshooting method for me is measure the output of the optocoupler on this USB-MIDI wire. But I didn't find an optocoupler on this MIDI USB wire PCB. There even do not have any one component has 4 pins on the PCB (based on my understanding, an optocoupler need at least 4 pins).
There only have one main chip on the PCB, it is possible that the optocoupler is embedded in that chip? Since the pin are too small I failed to connect my logical analyzer to those pin to check.
I have been following a tutorial that enables you to play around with the TXPOWER parameter of your wifi card / wifi adapter:
http://null-byte.wonderhowto.com/how-to/set-your-wi-fi-cards-tx-power-higher-than-30-dbm-0149606/
You can easily boost up your wifi range when increasing the TXPOWER.
Now, most people want to improve their wifi signal strength of their home router, right. But in my case, I would like my home router (which runs on a raspberry pi) to have a relative small wifi signal radius (say, a radius of 2 meters), so that you actually need to physically look for the pi home router when trying to connect to it.
I have learned that this tutorial does not do a thing with the wifi link quality and/or the wifi signal level and thus does not influence the wifi radius of my pi home router.
link quality & signal level
Do you guys have any ideas/thoughts about how to decrease link quality and/or wifi signal level (e.g Link Quality = 12/70 and Signal level =-10dBm) ? Is this even possible ?
I am using a Tp-Link TL-WN722N IEEE 802.11n USB - Wi-Fi Adapter.
WIRELESS LITE N ADAPTER 150M USB HIGH GAIN 1DETACHABLE ANTENNA WL-AP.
150 Mbps - External
First, I recommend reviewing this section from your link:
QUICK DECIBEL UNDERSTANDING:
Every 10 decibels is a 10X increase in power starting from 1 dBm equal
to 1mW... 10 dBm equals 10 mW, 20 dBm equals 100 mW, 30 dBm equals
1000 mW, and so on. Every 3 decibels is approximately double that of
the prior power, so 30 dBm is 1000 mW, if we add 3 dBm, then we can
double the power such that 33 dBm is about equal to 2000 mW.
It appears to me that you are able to modify the transmit power of your adapter as the tutorial states. Are you saying this is not working? If you set your transmit power to something extremely low (-30dBm, for example) you would effectively be turning off the transmitter. Keep increasing that value until you get your desired coverage radius.
If the transmit power parameter is not functioning as per the tutorial, then there are other means to achieve reduced coverage. The model you specified has a detachable antenna....so detach it. This would definitely reduce your coverage. However, if it reduces coverage too much, you could simply add an inline attenuator. Fortunately, your antenna uses an SMA connector which is very common. You can find many SMA attenuators on ebay with different attenuation values. Experiment with different values until you get the desired coverage.
And if that doesn't work, just wrap a bunch of aluminum foil around the thing lol.
I've been tinkering around with the BLE (Bluetooth Low Energy) connectivity classes quiet a bit lately and haven't been able to make it transfer data any faster than 1KB / 5 seconds. I believe, in the documentation, it says the max speed is 60 bytes per 20 milliseconds. With data transfer and counting the Ack transfer after each set of packets, I believe we should be able to go as fast as 1.5KB per second. So my code is around 7-8 times slower than it should be.
I'm just wondering if anyone has been able to do data transfer in BLE as fast as the documentation says it should be able to do. What sort of speed are you getting if faster than mine?
Thanks a lot
see at the guidlines of apple and you will see that a connection update request is required to speed up your connection.
https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf
I have min=20ms max 40 ms
I hope I could help
Roman
If you are able to use higher MTU size (negotiated by the iOS) then you would be able to increase the bandwidth even more, because there is a 4 byte L2CAP header and a 3 byte ATT header that wouldn't be transmitted more than in one packet.
If you are able to transmit 6 packets pr connection interval, then you would be able to put in 35 byte extra per connection interval (the 7 byte header would still be there for the first packet) The MTU size could also be split over several connection intervals, increasing the throughput with 7 more bytes pr connection interval. (Just takes longer time to assemble the packet again.) The max MTU size allowed by ATT is 515 bytes (Max size of att is 512 bytes + 3 byte header for opcode + handle)