I'm trying to send messages from a HC-05 arduino module to another following this tutorial : https://www.youtube.com/watch?v=mC8HDjRdcso
but with arduino uno's instead of nano's.
The AT configuration works fine but when I try to send messages it doesn't work and I don't know why.
The code is here : https://github.com/stechiez/Arduino/tree/master/HC05_master_Slave
(i've changed the RX, TX pins to 10,11 and of course the hc 05 adress is not the same)
This is how I've connected one hc 05 module to the arduino and the other one is the same.
And this is the output I have on the serials :
Related
I have an issue in being unable to recive the URC message from the modem whenever it receives an SMS.
I know that it receives them since i can find and read them if I use AT+CMGL but, i don't receive any notification when the modem gets them. I played around with the URC related commands but I've been unable to get it to work (other URCs work fine).
The modem is a BG600L M3 from Quectel and following is the sequence of commands i'm sending ("AT" is always omitted and the first command is literally "AT\r", basically an empty one).
//general config
AT\r
CFUN=1,0
E1
+QCFG=\"urc/ri/other\",\"pulse\",8,1
H0
&F
V1
+CMEE=1
&D0
E1
+CREG=2
+CGREG=2
+CEREG=2
//sms config
+CPMS=\"ME\",\"ME\",\"ME\"
+QINDCFG=\"smsincoming\",1
+CMGF=1
+CSDH=0
+CSCS=\"GSM\"
+CNMI=2,2,0,2,0
//doing some deleting and reading
+CMGD=1,3
+CPMS?
//getting the gps fix
+QGPS=1
+QGPSCFG=\"gnssconfig\",3
+QGPSLOC=1
+QGPSEND
//resetting the gms connection
+CFUN=0
+CFUN=1,0
//setting up the gsm connection
+QICFG=\"dataformat\",0,0
+QICFG=\"viewmode\",0
+QICFG=\"recvind\",1
+QICFG=\"tcp/retranscfg\",3,600
+QISDE=0
+QCFG=\"band\",0xf,0x80085,0x80085,1
+QCFG=\"nwscanmode\",1,1
+QCFG=\"nwscanseq\",010101,1
+QCFG=\"iotopmode\",2,1
// checking if it's connected
+CREG?
+QNWINFO
+COPS?
//Getting the time
+CTZU=3
+CTZR=0
+QLTS
+CCLK?
You can set AT+CNMI=2,1,2,0,0 , that should do the trick.
According to specification ETSI TS 127 005 V11.0.0 (2012-10)
+CNMI: <mode>,<mt>,<bm>,<ds>,<bfr>
by keeping <mt> value to 1 we should get indication when message is stored in ME/TA
<mt>: integer type (the rules for storing received SMs depend on its
data coding scheme
0 No SMS-DELIVER indications are routed to the TE.
1 If SMS-DELIVER is stored into ME/TA, indication of the memory location is routed to the TE using unsolicited result code:
+CMTI: <mem>,<index>
I'm writing a kind of wrapper over wlanapi. When receiving notifications via WlanRegisterNotification I'm getting unexpected media-specific module (MSM) notification with code 59 (which is 0x3B in hex). WLAN_NOTIFICATION_MSM MSDN page does not contain any helpful information. My wlanapi.h does not contain such value as well, in fact this enumeration is zero-based and contain only 18 values - from 0 to 17.
Does anybody knows the meaning of such notification, and why it is not documented at all?
Here is what I have so far.
Looks like this notification is a part of regular connection process. That is, I'm getting it when connecting to a wireless network - regardless of previous connection state. Here is the notification sequence which happens each time when I connect to a network:
wlan_notification_msm_associating
wlan_notification_msm_associated
wlan_notification_msm_authenticating
59 (0x3B)
wlan_notification_msm_signal_quality_change
wlan_notification_msm_associated and wlan_notification_msm_authenticating fires in the same moment of time, and then immediately (in 10-20 milliseconds) fires notification with code 59 (0x3F).
This notification has 16-bytes payload. Data structure does not look familiar to me, posting this in case if it looks familiar to someone (10 events):
80805E08 009B0000 F1F10800 C400D634 <-- Switching between two networks here and below in random order
D0D049FA 009B0000 A6A60800 01542A00
80805E08 009B0000 696902FF 00FF4C6F
80805E08 00C40000 04040E00 000093DF
80805E08 009B0000 04040900 6F009361 <-- Diconnect and connect to the same network
80805E08 009B0000 04000700 00009340 <-- Diconnect and connect to the same network
64640000 00450002 0400114D 00009363 <-- Disconnect and connect to another network
80805E08 009B0000 04040511 005B93E8 <-- Diconnect and connect to the same network
58580000 00450002 04000904 3D4293A1 <-- Connect to another network (i. e. switch)
80805E08 009B0000 04040100 10919316 <-- Connect to another network (i. e. switch)
Useful links
[Wlanapi] WLAN_NOTIFICATION_MSM NotificationCode 59 (Microsoft Q&A)
[Wlanapi] WLAN_NOTIFICATION_MSM NotificationCode 59 (c++ forums)
Will appreciate any help!
Update 1
Notifications sequence is the same when connecting via official sample:
HandleAcmNotification(type = ConnectionStart)
HandleMsmNotification(type = Associating)
HandleMsmNotification(type = Associated)
HandleMsmNotification(type = Authenticating)
HandleMsmNotification(type = Code59)
HandleMsmNotification(type = SignalQualityChange)
HandleMsmNotification(type = Connected)
HandleAcmNotification(type = ConnectionComplete)
Update 2
I've created a minimal test project on GitHub for this purpose - https://github.com/alexbereznikov/wlanapi-notification-code59-test.
Binary x64 release is located here - https://github.com/alexbereznikov/wlanapi-notification-code59-test/releases.
I'm getting the following output after successful connection to a wireless network:
This is by design.
The 0n59 notification code is a private notification code that is processed by the OS when the wireless network may be undergoing a network speed change.
For the end developer, this should be ignored by the end developer as it is not documented and subject to change in the future since it is a private notification handled by underlying OS.
Note:This will only be sent on newer OS now (Windows 10) when disabling and re-enabling the wireless network. This notification is not sent for older OS (example, Windows 7, Windows 8.1)
I'm using VEINS4.4, OMNeT++ 5.0 and SUMO 0.25
My project involves vehicles to exchange 5 types of messages and # of vehicles is more than 200 , and i some of messages not received by others and when i traced the problem , i discovered that they lost because 'A packet was not received due to biterrors or packet was not received correctly, sending it as control message to upper layer'.
I have found solution in one of sites and i have applied in my code ,and it solved the problem little bit because some messages were lost and now other vehicles received it ,but i have still some other messages are lost and not received by others with same previous error. I need to get rid of this problem, please how ?
The solution that mentioned in one of sites was to add jitters in sending:
1) To add this in initialize :
if (sendBeacon) {
scheduleAt(simTime()+ intuniform(1,3)* (par("beaconInterval").doubleValue()), sendRequestEvt);
}
2) Add this to handle self message :
scheduleAt(simTime()+(par("beaconInterval").doubleValue()), sendRequestEvt);
i have put dblrand() instead of intuniform(1,3) and no differrences
Using Andrew Rapp's XBee-API, how can I sample I/O data via a coordinator from more than two endpoints?
I have 17 Series 1 XBees. I have programmed one to be a coordinator (API mode = 2) and the rest to be endpoints. Using XBee-API I am sending a Force I/O Sample ("IS") remote AT command, unicast to each endpoint. This works perfectly well when there are up to two endpoints, but as soon as a third is added, one of the three always becomes non-responsive (times out with XBeeTimeoutException). It's not always the same physical unit that stops responding, but it is always the third one (for example, if I send Force I/O Sample to Device1, Device2, and Device3, Device3 will time out, and if I change the order to Device3, Device1, Device2, Device2 will time out.
If I set up more than three XBees, about 1 out of 3 will time out - but not every third one.
I've verified that the XBees themselves are fine. I've searched the Internet and Stack Overflow in particular to no avail. I've tried using a simple ZNetRemoteAtRequest. I've tried opening and closing the XBee coordinator serial connection once for all three devices, once per device, and once per program run. I've tried varying the distance between the coordinator and endpoints (never more than five feet apart). I've tried different coordinator configuration parameters (from the Digi documentation). I've tried changing out the XBee for the coordinator.
This is the code I'm using to send the Force I/O Sample request to each endpoint and read the response:
xbee = new XBee(); // Coordinator
xbee.open("/dev/ttyUSB0, 115200)); // Happens before any of the endpoints are contacted
... // Loop through known endpoint addresses
XBeeRequest request = new ZBForceSampleRequest(new XBeeAddress64(endpointAddress));
ZNetRemoteAtResponse response = null;
response = (ZNetRemoteAtResponse) xbee.sendSynchronous(request, remoteXBeeTimeout);
if (response.isOk()) {
// Process response payload
}
... // End loop and finally close coordinator connection
What might help polling I/O samples from more than two endpoints?
EDIT: I found that Andrew Rapp's XBee-API library fakes multithreaded behavior, which causes the synchronization issues described in this question. I wrote a replacement library that is actually multithreaded and correctly maps responses from multiple XBee endpoints: https://github.com/steveperkins/xbee-api-for-java-1-4. When I wrote it Java 1.4 was necessary for use on the BeagleBone, Plug, and Zotac single-board PCs but it's an easy conversion to 1.7+.
Are you using hardware flow control on your serial port? Is it possible that you're sending requests out when the local XBee has deasserted CTS (e.g., asking you to stop sending)? I assume you're running at 115200 bps, so the XBee serial port can keep up with the network data rate.
Can you turn on debugging information, or connect some port monitoring hardware/software to display the data going over the serial port to the local XBee?
I am very new to the 14443A protocol and mifare Clasic 4k Tag. I have a TRF7960A RFID reader interfaced to my device which is supporting Mifare mode after reading the Firmware version.
I got some information from my vendor but still i am facing issue in authentication.
I have pasted the Commands send and received in below.
Can any one help me in this about how the packet is being created?
Thanks in advance
Jethin
Set to Mifare Mode
Send : 0108000304FD00000
Returned : 108000304FD0000
Firmware Version 3.3[Mode Mifare]
Set Protocol
Send : 010A0003041000010000
Returned : 010A0003041000010000
Register write request.
Send : 010C00030410002101080000
Returned : 010C00030410002101080000
Register write request.
Send : 0109000304F0000000
Returned : 0109000304F0000000
Send : 0109000304F1FF0000
Returned : 0109000304F1FF0000
Scan Card UID
Send : 0109000304A0010000
Returned : 0109000304A0010000
14443A REQA.
(0200)(DB24C7A69E)[DB24C7A69E]
Received UID is DB24C7A69E
Authicate Block 04 Key is FFFFFFFFFFFF UID is DB24C7A69E
Send : 010A0003041850000000
Returned : 010A0003041850000000
Request mode.
[]
Send : 010D000304A2DB24C7A69E0000
Returned : 010D000304A2DB24C7A69E0000
14443A Select.
(0200)[18]
Send : 010E000304C0FFFFFFFFFFFF0000
Returned : 010E000304C0FFFFFFFFFFFF0000
Crypto1 set key.
Initialization ok
Send : 010F000304C16004DB24C7A69E 0000
Returned : 010F000304C16004DB24C7A69E 0000
Crypto1 authentication step 1.
!! 00 bytes and 00 bits received, expected 4 bytes and 0 bits. Abort
Send : 010C000304C23D6E98990000
Returned : 010C000304C23D6E98990000
Crypto1 authentication step 2.ý
Read Block 04 DATA
Send : 010A000304C830040000
Returned : 010A000304C830040000
Encrypted request mode.
!! cipher not initialized. Abort
Write Block 04 Write Data 12345678123456781234567812345678
Send : 010A000304C8A0040000
Returned : 010A000304C8A0040000
Encrypted request mode.
!! cipher not initialized. Abort
Send : 0118000304C8123456781234567812345678123456780000
Returned : 0118000304C8123456781234567812345678123456780000
Encrypted request mode.
!! cipher not initialized. Abort
A MIFARE Classic UID is always 4 bytes or 7 bytes, never 5 bytes. I don't know the TRF7960A, but I suspect that your problem is related to this. It would make the authentication fail: the tag will simply not answer. Any following commands requiring a successful authentication will also not work.