indianajones

Most recent activity

• How to properly handle incoming TCP/UDP data

  @indianajones started

  • 33 comments
  • 11,692 views

  @Gordon replied
• How to properly handle incoming TCP/UDP data

  in Pico / Wifi / Original Espruino • 5 years, 1 month

  

  Gordon, don't bother yourself with my pesky issue, it can wait. I'll ping you in mid/late-November or something. Until then, have a successful conference and product launch.

  Wait, did you say new product launch?? :-)

• How to properly handle incoming TCP/UDP data

  in Pico / Wifi / Original Espruino • 5 years, 1 month

  

  Well, I'm not storing any of this data, just accumulating the byte count, so there's no 16-bit limitation involved, in my code anyway. Regarding free space, it's no different than my comment here.

  At this point, I'm hoping Gordon will be able to reproduce the problem on his end using the sample data I provided.

• mDNS is working with Bonjour

  in Projects • 5 years, 1 month

  

  From what I can tell, it's used mainly for filtering out services you don't care about discovering. For example, Apple uses a service type called something like "_daap" (digital audio something player) from iTunes to find compatible players. So it won't find your printers or web servers or home automation devices, because it's filtering by that service type. So I can create my own service type and then discover only the devices I created, ignoring everything else on the network.

  I don't think it's a very big deal when you have only a few discoverable devices on your network, but if you had hundreds, filtering by service type is kinda cool.

• How to properly handle incoming TCP/UDP data

  in Pico / Wifi / Original Espruino • 5 years, 1 month

  

  @Gordon,

  I have a minimal nodejs app that extracts the data from the audio mixer. I was way off in the total number of bytes - the real count is actually 67,786 bytes for the entire state of the mixer. Here is the code that successfully got the message dump (obfuscated IP address):

  let net = require('net');
  
  let tcpSocket = net.Socket();
  
  let mixerIpAddress = "169.254.0.1";	// A&H Qu Series Mixer IP
  let tcpPort = 51325;				// ...and port
  let totalLength = 0;
  
  let sysExAllCall = new Uint8Array([0xF0,
  	0x00, 0x00, 0x1A, 	// Allen & Heath
  	0x50, 0x11,			// Qu series 
  	0x01, 0x00,			// Major/Minor version
  	0x7F, 				// All MIDI channels
  	0x10,				// ??
  	0x00,				// LSB is iPad bit, zero to disable requiring ActiveSense
  	0xF7]				// All-Call
  );
  
  function tcpConnect(details) {
  	tcpSocket.connect({port: tcpPort, host: mixerIpAddress}, function() {
  		console.log("...connected!");
  
  		tcpSocket.on('data', tcpOnMessage.bind(this));
  		tcpSocket.on('close', tcpOnDisconnected.bind(this));
  
  		// inform the Qu that we want telemetry from the device
  		tcpSocket.write(sysExAllCall);
  
  	}.bind(this));
  }
  
  function tcpOnMessage(chunk) {
  	totalLength += chunk.length;
  	console.log("chunk length is " + chunk.length + ", totalLength is " + totalLength);
  }
  
  function tcpOnDisconnected() {
  	console.log('client disconnected');
  }
  
  // Get connected
  tcpConnect();
  

  I've attached the file that represents the data dump (and there is no missing data from what I can tell). The data dump is a file of space-separated hex values, each representing a byte received from the mixer. At the very end, you'll see a few 'fe' single-byte messages, which is the MIDI ActiveSense byte sent once-per-second by the device. The fact that only 'fe' is being sent at the end of the data means the mixer has completed its dump of NRPN and SysEx data.

  I dumped the messages as they arrived - no buffering or messing with the data. Each newline represents the end of the data for that particular message. If you need the file in a different format, let me know and I'll see what I can do.

  Edit: how fast can the wifi go? For my project to work, it's gotta be pretty close to real network speeds. I saw 13Mbps was being mentioned on the internet - is that possible?

• mDNS is working with Bonjour

  in Projects • 5 years, 1 month

  

  I tweaked Gordon's example code snippet for flexibility:

  wifi.enableMDNS = function(hostname, serviceType, port, callback) {
  	let mdns = "AT+MDNS=1," + JSON.stringify(hostname) + "," + JSON.stringify(serviceType) + "," + JSON.stringify(port) + "\r\n";
  	this.at.cmd(mdns, 500, function(d) {
  		callback(d);
  	});
  };
  

  Now you can specify the service type and port, like this:

  wifi.enableMDNS("esp-livingroom", "iot", 80, function(result) {
      console.log("result is " + result);
  });
  
  

• How to properly handle incoming TCP/UDP data

  in Pico / Wifi / Original Espruino • 5 years, 1 month

  

  E.getErrorFlags() returned nothing. My stripped-down version of the code merely prints the number of bytes in each tcp on 'data' call. That version is calling dumpArray, isn't copying data, is only printing the count of data in each on 'data' call.

  wifi.turbo() didn't help with respect to lost data, but boy the data arrived wicked-fast! I'm keeping that one.

  I'm working on making a node version, stripped down, which is what I'll post when done.

• mDNS is working with Bonjour

  in Projects • 5 years, 1 month

  

  it works!
  The device can now be discovered. Any pointers on how to discover other devices? I think I need to send a UDP packet on 224.0.0.251:5353, but (a) I don't know what data to send to that destination, or (b) if that's the right thing to do.

• mDNS is working with Bonjour

  in Projects • 5 years, 1 month

  

  Cool, thanks @Gordon. So I'm not sure where 'turnOn' and 'at' objects reside. It sucks that you have to hold my hand so much. How do I use this function - I can't just paste it into my code, because 'turnOn' and 'at' are undefined.

• mDNS is working with Bonjour

  in Projects • 5 years, 1 month

  

  I got the ESP8266 fw update installed, validated it was 1.5.4, but still no difference. So here's what I'm doing:

  I'm calling wifi.setHostname() in the wifi 'connected' callback, and I get a success on that.

  Then I call 'dns-sd -B _http._tcp' from the Mac Terminal to browse for the device, not using Windows.

  I fear that I need to do more, but I don't know what it would be.