Search results for:

Congrats on your inbound boards.

This shouldn't be too hard to solder. I'd suggest you read up on 'drag soldering', and test it out a few times before trying it with your 'production' components.

There's an article here: http://www.howardelectronics.com/jbc/dra­gsoldering.html

Edited: Removed link to the first video I posted as this one is much better

SMT soldering video here: http://www.youtube.com/watch?v=b9FC9fAlf­QE

@d0773d Awesome! Thanks for posting the update, and sharing the great news. I'm glad that someone at eevblog was able to help you out. That forum is becoming more and more useful, specifically for electronics & design related discussions.

Let us know how the boards look when they come in, and post a pic if you get a chance.

Cheers.

I can answer your question regarding the meaning of the 3.3v label on the reference diagram.

The pins labeled "3.3v" are only tolerant of 3.3v input voltage. Whereas, the pins without the "3.3v" label are tolerant of up to 5v input voltage. The data sheet has a pinout table on p 30-35, where this can be verified.

I do not believe the output voltage is any different on those pins, but I'll defer that to Gordon.

I'm glad you found a process that works for you @user7114 - (wow that username feels very dystopian )

Windows does have a default setting that hides file extensions by default, as @Gordon mentioned. This may be what's causing the difference in what you're seeing.

This is one of the first options that I change when using a computer, so I didn't even think of it.

The setting is buried in Windows 8, but I'll try to describe where its at if you want to see how your computer is set and/or change it.

• Open control panel,
  
• If view-by is set to categories, change it to large icons
  
• Within control panel, select the Folder Options icon
  
• Within the Folder Options dialog box, choose the 2nd tab titled view
  
• go to the bottom section labeled Advanced settings
  
• UNCHECK the option entitled Hide extensions for known file types
  
• click apply then ok (or just ok) to close the dialog box
  
  

You should now see the file extensions of all of the files when viewing a directory on your computer. (The extensions were always there, Windows was just being helpful and hiding them for you.)

I hope this helps.

Cheers.

I'm on Windows 8.1, Chrome Version 35.0.1916.153 m, and just pulled the latest Web IDE from Github (which now shows 0.45)

The file-save dialog defaults the filename to code.js

My mistake, i just re-read your questions/comments and you are correct. I apologize, as I didn't even notice the drop-down thing, as I was just happy that the save-as box popped up at all.

Yes, the IDE number on the Dev/github version IS the same as the release version. But, i'm not sure if release has been updated or not.

And Yes, the 'save as type' drop-down is fixed as 'all files', but the default filename should end in .js (at least)

Sorry & sorry that I couldn't help ya.

my comment was based on the dev IDE from github, as he linked above. i'm not sure is the 'fix' got rolled into the Chrome Web store and/or if the changes have been approved by Google yet.

If you really need the update, you can always install the dev version.

@Gordon Excellent, as always. Thank you.

Is the 1v65 WIZnet bin posted anywhere?

I'm using @DrAzzy build from the 32-bit Int Switch thread, but I'm unsure if that's the same as the official 1v65. http://forum.espruino.com/conversations/­1555/

Also - will the WIZnet module always require a separate build, or can this be rolled in at some point?

Hi @DrAzzy Yes, I can confirm that the Adafruit connectors work with the jack on the Espruino.

I have yet to receive a JST connector from Adafruit that doesn't work with the Espruino. Although, they do usually use the generic term "JST cable" in the product descriptions.
EDITED TO CLARIFY: I believe that PH sized connectors are the only type of 2-pin JST connectors that Adafruit (and Sparkfun) uses. This connector size seems very common within the open-source, embedded module community.

As for the naming differences, I believe they're both correct - PH is the name of the series of connectors, whereas PHR-2 is a specific model number for a "2-pin connector housing"
EDITED TO CLARIFY: As I understand it, JST is simply a type of connector, whereas PH is a specific size of JST connector. Thus all 2-pin PH connectors should be the same size, and thus interoperable.

The Datasheet for PH connectors can be found on JST's PH connector page, and page 2 shows the Model Numbers for the different variations (different pin counts, surface mount, etc...) http://www.jst.com/home8.html

@d0773d - no worries. Sorry, I didn't realize that you only wanted one row of pins.

Unfortunately, I'm not aware of any adapter that brings .4mm pitch items out to a single row of pins. I've seen such adapters for smaller pins counts in more common pitches, but .4mm adapters are fairly rare.

You might try posting to the forums at http://www.eevblog.com/forum/

I realize this thread is old, but I'm posting some info for anyone searching in the future.

@ZeroEcho - as you've likely determined, the Adafruit battery you linked DOES have the same connector as the Espruino.

In fact, all of the LiPo/LiPoly batteries sold by Adafruit and SparkFun have the correct connector.

Adafruit also sells the connector with pre-attached wires: https://www.adafruit.com/products/261

There are adapter boards from Bellin Dynamic Systems and Schmartboard for .4mm pitch.

The Bellin B508 module includes two .4mm to .100" breakout modules. http://www.beldynsys.com/p508.htm

The adapters for .4mm pitch are on the back. They're designed to snap apart, into modules as pictured below, then you can cut them even smaller if needed:

note: the sample photo is for a different pitch.

The SchmartBoard Module is the 202-0047-01 http://www.schmartboard.com/index.asp?pa­ge=products_connectors&id=319

I'm not sure which would work best for your project. But, it seems like either would be quicker than spinning your own PCB.

@azrobbo

@Gordon thank you so much for tracking this down! I can easily code around this until the next release comes out.

Cheers!

Thanks folks for your feedback and info.

@user6350 - Thank you so much for providing this awesome code-base! I'll definitely leverage what I can from that once I start working on the actual GPS project again. (Right now I'm kind of obsessed with understanding what is causing this leak.)

@Gordon - I'll help out however I can to track down this memory leak, as it might effect other modules and users as well.

I have limited time today, but I was able to log the direct serial output of the GPS before and after 'lock', so we can examine the data-stream.

Here's a sample from the data-stream, before GPS-lock

$GPRMC,235948.318,V,,,,,0.00,0.00,050180­,,,N*4A
$GPVTG,0.00,T,,M,0.00,N,0.00,K,N*32
$GPGGA,235949.318,,,,,0,0,,,M,,M,,*42
$GPGSA,A,1,,,,,,,,,,,,,,,*1E

Here's a sample from the data-stream, after GPS-lock (Note: the checksum bytes won't be accurate, as I've anonymized the location data.)

$GPGGA,044236.000,4807.0380,N,01131.000,­W,1,8,0.97,545.4,M,-46.9,M,,*65
$GPGSA,A,3,21,29,25,05,26,15,18,12,,,,,1­.35,0.97,0.94*06
$GPRMC,044237.000,A,4807.0380,N,01131.00­0,W,0.06,545.4,160614,,,A*76
$GPVTG,327.20,T,,M,0.06,N,0.11,K,A*3F

I manually executed some of the library definitions with pre-lock data. Note: I have a similar output generated with post-lock data, but since it executes as expected, i'm not sure it adds any value. I can post it if anyone thinks it will help.

var line = "$GPGGA,235952.319,,,,,0,0,,,M,,M,,*49"
="$GPGGA,235952.319,,,,,0,0,,,M,,M,,*49"­
var d = line.split(",")
=[
	  "$GPGGA",
	  "235952.319",
	  "",
	  "",
	  "",
	  "",
	  "0",
	  "0",
	  "",
	  "",
	  "M",
	  "",
	  "M",
	  "",
	  "*49"
	]
var dlat = d[2].indexOf(".");
=-1
var lat = (parseInt(d[2].substr(0,dlat-2),10)+pars­eFloat(d[2].substr(dlat-2))/60)*(d[3]=="­S"?-1:1);
=NaN

I'm wondering if there could be a leak caused by one of the string parsing functions used to calculate the latitude, longitude, fix, satellite, or altitude vars, when using a '-1' parameter and/or when the result is "NaN". Since these functions execute several times a second, even a small leak would become significant very quickly.

Alternatively, could this be some sort of buffer overflow with the Serial Port? I've verified that my module is running at 9600 baud, so I don'd see how this is possible.

I have the following tests planned for tomorrow:

1. I'll switch the code to using your library as a local function as you suggested.
   
2. I'll comment out sections of the code and try to create the smallest piece of code that still exhibits this problem.
   
3. I'll remove the GPS & Serial functions entirely, and make a function that uses the parsing functions (as defined in the library) to parse our pre-defined sample data taken from the pre-lock GPS capture. Then set this function to execute once a second, and monitor the memory usage.
   
   

I believe these steps should help us determine the root cause of the leak. Are there other test that I should try?

Are there other additional environment settings that I should capture in addition to process.memory() and trace() ?

Hi Folks -

Today, I encountered a memory leak with a simple bit of code that's interfacing with a GPS module using the GPS library. Specifically, about 2-3 blocks of memory were leaking every 5 seconds (or so) until the GPS got a 'satellite lock'. This may have something to do with how my module transmits data pre-lock, or could be a mistake that I've made (as I'm new to Espruino) . In case it's relevant, the GPS Module that I'm using is the Adafruit 'Ultimate GPS Module' with MTK3339 chipset.

Initially, I thought the memory leak was something in my code, and I was in the process of tracking that down when the GPS got a 'lock' and the memory leak stopped. I stripped my code down to the minimum, and grabbed three process.memory() and trace() dumps, two before the 'satellite lock', and one after.

Here's the code that I was testing this with:

Serial4.setup(9600,{tx:C10,rx:C11});
var gps = require("GPS").connect(Serial4, function (data) {
		if ((data.time.substr(-2))=="00") {
			console.log("time = "+data.time);
			console.log("lat = "+data.lat);
			console.log("lon = "+data.lon);
		}
});

Immediately after uploading the code, process.memory() returned the info below. The matching trace file is called 'trace-start.txt'

{"free":1654,"usage":146,"total":1800,"h­istory":70,"stackEndAddress":536909536,"­flash_start":134217728,"flash_binary_end­":134435300,"flash_code_start":134443008­,"flash_length":262144}

A few minutes later process.memory() returned the info below. The matching trace file is called 'trace-422.txt'

{"free":1378,"usage":422,"total":1800,"h­istory":70,"stackEndAddress":536909536,"­flash_start":134217728,"flash_binary_end­":134435300,"flash_code_start":134443008­,"flash_length":262144}

Finally, the satellite locked when 576 blocks of memory had been used, and the memory leak stopped. process.memory() returned the info below. The matching trace file is called 'trace-satlock.txt'

{"free":1224,"usage":576,"total":1800,"h­istory":88,"stackEndAddress":536909536,"­flash_start":134217728,"flash_binary_end­":134435300,"flash_code_start":134443008­,"flash_length":262144}

I'd be interested in anyone's thought of ideas on this problem.

Thanks.

I can confirm this fixed it on my Win 8.1 system on Chrome Version 35.0.1916.153 m. Thank you sir.

Cheers!

I can confirm that I'm having this same issue on Windows 8.1 - 64 bit.

1. Its a normal Desktop install, and this computer has only had Win8 &
   8.1 on it.
   
2. It's the latest up-to-date, normal Chrome Version 35.0.1916.153 m.
   
3. Chrome is running in "Desktop mode"
   
4. The new Win8 UI is completely hidden on this machine.
   
   

I'm happy to help you test this; ping me if I can help.

Cheers.