Search results

Heads up, the "QNEthernet_WIFI-0.37.0" GitHub branch is now the default "main" branch. Here is the link: https://github.com/wwatson4506/QNEthernet_WIFI

@KurtE - You probably saw the above post. I did see your post on the Arduino forum about the reset delay. If you are talking about the WiFI reset would it be this: /////////// //WL_ON pin /////////// pinMode(wlOnPin, OUTPUT); // Pull high to activate WLAN digitalWriteFast(wlOnPin...

@gigapod - Nice to here. I had a computer go down:cry: It took out my Windows drive completely and messed up the Linux drive which I am trying to recover right now. Fortunately I have the WIFI and Bluetooth backed up on my laptop and another desktop. Whew!!! I did loose a lot of personnel info...

Isn't that the truth:)

Awesome:love: I love the graphics. Can't wait to see it after completion...

I forgot about this. Just for the heck of it I wanted to try it out between the T41 with the CYW4343W chip and another T41 with the CYW43439 chip. Even though the messages to match they appear to transfer properly: [TEENSY TX] Distributing state struct to ESP32... >> ESP32 confirmed structural...

One more thing, I fixed the problem with the "Sparkfun_teensy_Bluetooth" library showing up in the "INCOMPATIBLE" menu in Arduino 1.8.19: name=SparkFun_Teensy_Bluetooth version=1.0.0 author=SparkFun Electronics <techsupport@sparkfun.com> maintainer=SparkFun Electronics <techsupport@sparkfun.com>...

@mjs513 - Got pretty much the same results as you did with the UDP test: Setting link up Local IP = 192.168.7.235 Subnet mask = 255.255.252.0 Gateway = 192.168.4.1 DNS = 75.75.75.75 UDP Throughput Test with IPERF Packets: 0 | Lost: 0 (0.00%) | Throughput: 0.00 kbps...

@mjs513 - Probably not going to have much time today to play with it today. It interesting to see that both boards perform about the same. Will play with it tomorrow (y)

It's late but one more test with wired Ethernet and MTU set to 4018 temporarily running "SimpleHTTPClient.ino" we get: Response stats: 88620 bytes in 0.137245 seconds Maybe test UDP response times?

Gave up on iPerf very inconsistent when testing any thing including my desktops and laptop. Anyway, there is one example that is consistent and that is "SimpleHTTPClient.ino". With original MTU and RX/TX buffer sizes I get: Response stats: 88485 bytes in 0.326005 seconds With MTU at 4018 and...

Have make dinner and take the wife to work. Hopefully I have time to test tonight:)

@mjs513 - Maybe https://sourceforge.net/projects/iperf2/files/ ?

Sorry for the delay I had to lay for a nap. These 3:00 AM mornings are hard for me to keep up with:) Anyway, output from QNEthernet starts here in "driver_CYW4343W.cpp" line #186: //============================================================================== //...

Ok, could not leave it alone. In "event.h" I set: #define TXDATA_LEN 2048//1600 <------ as per SDIO specs #define RXDATA_LEN 2048//1600 <------- as per SDIO specs In "driver_CYW4343W.h" I set: #define MTU 2318 #define MAX_FRAME_LEN 2318 /* Does not include the 4-byte FCS...

In the "iPerfServer.ino" sketch @shawn mentioned this: // [/// Under Repair ///] // NOTE: This example doesn't currently behave well. // I could use some help fixing it; my gumption for this is low. // [/// Under Repair ///] // Which explains the erratic behavior of that sketch. Sometimes...

I think it has to do with the way data is buffered in the CYW4343x driver. You can actually raise the MTU size but you take a hit on through put as you raise the MTU size. The buffering has not been addressed yet in the driver...

Back at home now. That change to the MTU setting fixed the issue here as well as another two I had not got into yet. "SimpleIPerfServer.ino" before MTU change: ------------------------------------------------------------ Client connecting to 192.168.7.235, TCP port 5001 TCP window size: 16.0...

Sorry not at home.

You guys are 😊

@mjs513 - It seems the sketch is not getting a response here: // Reads the response and returns whether complete. bool readResponse() { // Read what's available from the client and print it int avail = client.available(); if (avail > 0) { printf("Is Available...\n"); int read =...

Tested with both. Wired worked: [Start] Starting Ethernet with DHCP... [Ethernet] Link ON [Ethernet] Address changed: IP = 192.168.7.213 [Request] Connecting to api.open-meteo.com:80... Sending request... Built URL Path...

@mjs513 - I think you found something. It definitely hangs. So in "qnethernet_opts.h": // 1 == Disable T41 native ethernet IF and enable T41 CYW4343W IF (Default). // 0 == Enable T41 native ethernet IF and disable T41 CYW4343W IF. #ifndef ARDUINO_TEENSY41_CYW4343W #define...

The home town info/forecast: Enter City name: New City: bellingham [0/3] Map City to Location... Name Query:/v1/search?name=bellingham&count=1 ====================== Map City ====================== Name: Bellingham latitude: 48.759548 longitude: -122.488220...

These are the kind of examples that help validate a library:) Practical application. Downloaded the zip file and will play with it...

Dang, I think that other IC is the added voltage regulator:eek: I did not catch that at first. The inverter chip is the one next to the CYW43439 chip and the RX pin label. Unfortunately they look the same:confused:

My setup sounds the same as yours except my board had the inline female sockets with long male pins solder to it, post #298...

The download zip file should be showing "SparkFun_Teensy_Bluetooth-Updated.zip". See post #298 for my setup...

Just for the heck of it I started up my windows machine and tested the library on it. It worked there as well :confused: I am going to find out why the library is showing up in the "INCOMPATIBLE" portion of the examples menu...

OK, just downloaded https://github.com/wwatson4506/SparkFun_Teensy_Bluetooth/tree/Updated onto another desktop and put the library into Arduino/libraries. Using Arduino 1.8.19 and TD1.62 I uploaded "BLE_Scan.ino" to the T41 and the output was: CYW43439 BLE Scan Example [SFBLEDevice] init()...

@defragster - Not sure why it is not working for you. I'll download the library on another desktop and make sure it is working. In the mean time here is the scan sketch in full: /** * BLE_Scan – SparkFun CYW43439 Bluetooth Library Example * * Continuously scans for BLE advertisements and...

Fixed...

Here is the temporary working Sparkfun Teensy Bluetooth library: https://github.com/wwatson4506/SparkFun_Teensy_Bluetooth/tree/Updated. To use the two pins of the inverter must be shorted together as per post #335. Flow control has been disabled in each of the four sketches. the Bluetooth scan...

@KurtE - If you don't mind I would like to add your example to my Ethernet examples repo on GitHub. I checked the other two Bluetooth examples and they also seem to work. It is really interesting that this all works without the flow control signals. once we get the new boards with the working...

Found it:ROFLMAO: The other examples have the wrong pin settings and the wrong Serial port. changed that on on of the other sketches and it works. Got errands to run so I can't test the other two until later...

Here we go again: CYW43439 BLE Scan Example [SFBLEDevice] init() [SFBLEDevice] localName: SF-Scanner [SFBLEDevice] btRegOnPin: 28 [SFBLEDevice] rtsPin: 36 [SFBLEDevice] ctsPin: 33 [SFBLEDevice] starting BLE_Controller... [BLE_Controller] begin() [BLE_Controller] bringing...

Thanks Mike :D

Disabled RTS/CTS flow control in "HCI_Transport.cpp lines 16 and 17 and shorting the two pins on the inverter indicated above: // attachRts()/attachCts() are only available on HardwareSerialIMXRT // (Teensy 4.x), not the generic HardwareSerial base class. // if (_rtsPin >= 0)...

This library looks like it might be fairly easy to integrate into the current driver using other BT drivers for reference...

Just glad you caught it now. That could really mess with the testing :D

Just started in on an attempt to setup Bluetooth usage. Looks like there is a lot to learn. I might be a little quiet for a while...

Got it :)

Search on this subject: SD card radiation levels and effect on nearby WIFI antenna reception Apparently the SD card radiation is negligible due to the lower operating frequency of the SD card as compared to the 2.4GHz operating frequency of the WIFI device. Of course anybody with the correct...

@defragster - As far as signal strength goes there are settings in the NVRAM firmware file where that can be adjusted but one must be careful as you can actually damage the chip if you go to high with the settings as well as violating FCC regulations for the US. See post #296 towards the bottom...

Reverted back to non auto detect library. Repo updated. Still have a backup of the auto detect version zipped up. That's enough for today:sleep:

I agree...

@jmarsh - You are correct. I just checked and it is pulling in the other three includes data:( With the auto detect version and uploading "SNTPClient.ino" I am seeing: Memory Usage on Teensy 4.1: FLASH: code:128944, data:682536, headers:8740 free for files:7306244 RAM1: variables:59232...

There are six firmware files used. Three for each of the devices, Firmware, CLM and NVRAM. the NVRAM files are small around 700 to 800 bytes. The CLM files are 3208 and 7222 bytes. Finally the biggies are 230321 and 419798 bytes. Combined that would be a pretty good hunk of flash memory being...

@SparkFun - Sorry to confuse you I have my answer. I could not remember if an #included files contents were automatically included even if none of it's contents were used in the code. Answer is no they are not included. that means I can include the firmware files for both the 1YN and 1DX devices...

Correct me if I am wrong but if nothing is used from a particular include file the contents of that file will not be brought in and compiled, Right?