[quote author="ian"]I'd really appreciate your feed back on: 1. Yellow or white tubing?[/quote]
White, definitely. Also it will be a better platform if you ever start experimenting printing in colour (to match the wire colour?).
Quote
2. Left, right, or center justified printing?
Well that depends on whether your cable goes from left to right or right to left on your bench. But since left-justified is easier to realize than right-justified, go for the left.
Also I'm not convinced longer housing is that great an idea. In your pictures the wrap is way too long (I understand it was to print two label styles), and it kind of decouples the pin from the wire colour, which is what becomes important after a few uses and you've memorized what colour is what signal. Since the heat shrink label has to be longer than the housing and overlap the wire, regular sized housing sound good, especially given that the heat shrink itself will become the new handle since it's relatively stiff once shrunk.
[quote author="jeanmarc78"]Have you considered using a commercial cheap router such as the tp-link tl-wr703. You can find them for around 20$ on ebay (with the AC adaptor and shipping included). Multiple hardware upgrades have already been described.[/quote]
Yes, I've considered using a System-on-Chip with a full fledged Linux. The problem is that I consider the quality of the software stack of such systems to be relatively low, and particularly hard to upgrade and improve because of the sheer size of that software (Linux alone has millions of lines of code, and add to that a full userspace) and the poor documentation of these SoCs (many vendors just provide botched drivers for an old version of Linux and call that support).
So for this project I'd like to keep the software stack as small as possible, with just a libc, Lua, and all the rest will be user-defined. I plan to provide some libraries to ease accessing the MCU peripherals from Lua, but I don't want to force any programming paradigm on the users, so they can experiment with new kinds of multi-tasking or software architecture.
For some time now I've been thinking about creating a general purpose development board in the same category as the Arduino, ie. without a high level operating system, but that I could program with the Lua programming language, because I'm a big fan of that language. A project called eLua aims at running Lua on various kinds of microcontrollers, but I'm looking for something slightly different.
The main constraint to run Lua on microcontrollers is memory size. The Lua interpreter is fast enough to be able to run on most processors, but even if it's one of the most compact scripting language interpreters around, it still require a few hundreds kilobytes of ROM, and at least as much RAM, and potentially much more to run large programs. And even if many microcontrollers now have many hundreds of kilobytes of Flash, RAM is usually much more scarce. And this is not a problem for C/C++ programming, so most general purpose dev boards don't provide external RAM.
So this project is about packing a relatively fast microcontroller, but not complex enough to require a high level OS (like Linux for SoC-class chips), with a big RAM chip. I picked a STM32F427, because I have some experience with the STM32 family, the core is a Cortex-M4F (floating point will help running Lua), and it is one of the few Cortex-M microcontrollers with an SDRAM controller. SDRAM is desirable over SRAM because it's much more dense and there are 256Mbits (32Mbytes) chips available for a few dollars.
Apart from that I attached the MCU to an Micro-SD card slot, two USB OTG ports, a 5V DC input, and all the other available pins (the SDRAM uses quite a lot of the 144 MCU pins) are exposed as user-available I/Os.
I've completed an initial schematic and a tentative routing (10cm x 6cm, 2 layers) in EAGLE, and I'd be happy to have comments before I order the first PCB batch, especially on the schematic. Here are the current files:
Following good reviews from this forum I decided to try the Smart-Prototyping website to produce some PCBs for a new iteration long-lived project of mine. Here is what happened.
2013-10-17
The board is designed with EAGLE. It's very small, so I assembled several copy of them into a 10cm x 10cm panel using some scripts of mine. Also I don't have a decent soldering iron, so I decided to order one of their cheap Atten ones. Here is the order:
Quote
PCB Prototyping - Quantity: 10 - Max X-Dimension: 10 cm - Max Y-Dimension: 10 cm - Layers: 2 - PCB Thickness: 1.6 mm - Copper Thickness: 1 oz - Surface Finish: HASL (Hot Air Solder.. - Solder Mask Color: Green - E-Test Pass: 95% - Solder Paste Stencil: yes (max. 19x29cm) - Separated Sub-Boards: no - Gerber Files: jvuarand-panel-20131.. Soldering Station Atten AT936B - AC Voltage: 220V - Power Plug: UK, ...
This adds up to $60.02, shipping (to the UK) is $38.26, total is $98.28.
2013-10-28
I receive an email telling me the order has been shipped on the 24th of october.
2013-10-30
I'm surprised to receive my order, shipping was very fast. That's the good point. But there are several problems with the order.
First the soldering iron. It was shipped with an australian, non-detachable, power plug. So I can't use it in the UK. And I can't return it because of some export restriction on electronics goods from the UK to China (at least that's what my post office told me). I later managed to replace the power cord (by opening the device and unsoldering and re-soldering another cable), but at that price the crap PCB inside barely survived my rework. It works, let's move on.
The PCBs are very well packaged, it looks good from the outside. Once opened, I have shiny new PCBs perfectly well routed around my different sub-boards, with the breaking tabs, the tooling tabs and holes, everything.
But I notice all the holes are plated, even those that shouldn't be (those defined as holes and not vias in EAGLE, and that don't connect to any trace on top or bottom). So the tooling holes are too small for me to insert the pins they were designed for (I have one of these). Also the holes along the breaking tabs (I used this scheme) are plated, so they are too stiff to break properly, and they leave some metal cylinders on the PCB edge when I break them.
Finally the stencil. First impression, it's big. But the two faces of the PCB are squeezed against each other at the center, I would have appreciated more space between them. But something looks off, something is missing. I realize my tooling holes are missing, so once again I cannot use the stencil with my Stencil8 fixture. Since the holes were supposed to be generated by my panelizing scripts, I double and triple check the Gerber files with several different tools. The 2.5mm holes are present in the paste files. After a more in-depth inspection, I realize many pads are different from my Gerber files. I'm starting to wonder if they really used it, or somehow re-generated it from the copper files.
So largely disappointed I send them a message through their website.
2013-10-31
I receive the following message:
Quote
this is Cherry from smart-prototyping team. Sorry for my late reply. We are sorry for this mistake. We will report this issue to packing department and it will not happen again in the future. For the stencil, could you please send us a picture of stencil so that we can know more about this issue. If it is indeed mistake from factory, we will redo a stencil and ship it to you.
Sorry for any inconvenience it may cause and thank you for your feedback so that we can improve our service.
This reply is not late at all, contrary to the following ones. I send them the following pictures. First a render of the board with my grbv tool:
Then I modified the tool to render what the stencil should look like:
And then a picture of the actual stencil, from a similar angle:
2013-11-10
No news for 10 days, I send Cherry another message. I get the following reply the next day, with a copy to some guy from noa-labs.com (which I assume is the company they sub-contract the PCB manufacturing to):
Quote
sorry, your last email got trapped on my spam folder. I find it now, I will check it and send you reply soon.
2013-12-02
Three more weeks without answer. I send Cherry yet another message. Next day again I get the following answer:
Quote
sorry for late reply. We were discussing with factory about the default rule in stencil fabrication. Factory made the change to stencil with reasons.
For those weird pad shape. It is in fact for avoiding the solder beads, when pad is bigger then 0805. This is why factory made such pad shape.
For cross in pad, there is default rule in stencil fabrication that the stencil pad will be reduced to 60% - 70% of the pin pad(this is for avoiding short trouble caused by overflowing solder). If the bottom of QFN QFP grounded pad is bigger than 1.5MM, there will be cross, minimum width of the cross is 0.3MM (if grounded pads are already small, such as 1.0mm, pad can be made 100% out)
For tooling hole, when using the drill there will not be the plated. When using pad and via then will have the plated. If you would like to keep the hole in the stencil , you should have made the hole also in the solder paste layer. These are default rules in stencil fabrication. We will update rules to our website soon.
So I check again the tooling holes in my paste Gerber files, and they are there, so I send another email to complain about it.
The following day the guy from Noa Labs sends the following answer:
Quote
For the solder paste, you file is totally fine, this is our mistake for forgot to make the locating hole on the stencil. Sorry about this.
For the future this will not happen again.
I immediately send them an email asking whether they will refund or replace the stencil.
2013-12-26
It's been more than three weeks now. No word from them. I've sent them a second unanswered email. I just realized typing this post that Cherry offered a stencil replacement in one of her earlier emails, but I guess they're not very willing to do it even though they admitted the mistake.
Also regarding the plating of non-via holes, EAGLE puts them on different layers. It is possible to change the CAM export file so that only vias (and through hole pads) are exported to the Excellon file, and the holes are exported only to the mechanical Gerber (this is already done because EAGLE also draws the hole borders in the Dimension layer). I've told them to modify the EAGLE export script they offer on their webpage, but as of today it still hasn't been updated.
So if you have non-plated holes on your designs, at the very least (if you're prepared to deal with all of the above) modify the export CAM script so that the hole layer doesn't end up in the Excellon TXT file.
I don't know for Mats, but I recently ordered with Smart-Prototyping, and I've had a mixed experience. I have still a pending issue with them, but I'll give a thorough review soon.
I've had a look at your data. It appears that the outline in the GML file is not closed properly. Zoom in the upper right corner using another basic Gerber viewer or your source data editor. There are two corners there, separated by about 0.2mm. Also there is an overlapping segment about 1mm long, which may prevent the merging of the two corners even if the merge radius was extended.
Yes, sure, send me the files and I'll have a look. The tool support irregularly shaped PCBs, but the outline data must be in a form that is unambiguous. Your PCB fab loads the files with human intervention to resolve ambiguities. If I can't support your files directly at least I'll be able to tell you how to modify them so that they give the expected visualization.
There is no standardized method to declare the generator, but there are comment directives and each app can declare itself with them (or not). There are even tentatives of pseudo-standard extensions more or less based on comment directives or other generic headers to add more meta-data than anticipated in the spec (which itself changes quite regurlarly already).
In the last board you posted there is no comment indicating directly what was the app, but there are some of these comments containing meta-data so you may be able to determine what app generated them with some googling. For example (G04 is the comment directive):
And as for the macro, it's not that complicated, it's for the pads with rounded corners. It's made of a horizontal rectangle, a vertical rectangle, and four circles in the corners to make a rounded rectangle. But yeah, you can do pretty complex stuff with these macros (which can have arithmetic expression, define named variables, etc.). While writing all my Gerber parsing code I was really regretting that EAGLE doesn't use all these nice features to generate cleaner Gerber files.
I just released a new version tagged 20131012T0005. It fixes the problem matseng has (though his board doesn't load perfectly yet, there is too much unwanted stuff on the mechanical layer).
Among the new features, I introduced a new mouse rotation and translation scheme. The translation scheme is simply superior to the other one, so you'll probably like it. The rotation scheme though is different, and both the old and the new have their advantages. If you want to revert to the old behaviour for one or the other, you can edit your grbv.conf file and add one or two of these lines:
For the very curious, this version (and maybe one or two before that) supports displaying 3D models for parts. Since it's not very easy to use yet I won't talk too much about it, I'm planning to work on it some more before officially documenting it. But if you want to give it a try, look at the source code and ask here for detailed explanations if the code is not clear enough.
There is a double problem here. Your file use A) a composite aperture macro containing several primitives and B) some of these primitives are of the type "Center Line, primitive code 21".
Fixing B is relatively trivial, I just overlooked the case (and a few related ones) because I didn't have a test file for it.
Fixing A is not as straightforward, since having multiple primitives in an aperture may result in a shape with several contours, and eventually holes. Complete support for this would require extensive modification of my drawing code. In your case the final macro shape has a single contour and no holes, so I can probably hack a special case for these.
@Sleepwalker3: You can run either the .exe or the .com, and you can drop a single file on the window (but it's probably more useful to drop a bunch of related files at once). You can also load the full LilyPad board by pressing F5 (if you didn't change your key bindings). Can you run the .com instead of the .exe, and copy and paste the console output so that I can see where it gets stuck?
@kiate: I didn't receive the automatic error messages (you disabled them or have a proxy/firewall blocking outgoing HTTP). Can you send me an email with the error-report.txt file that you should have in your "Gerber Viewer" directory?
No, I didn't do any performance modification recently.
The only time I witnessed such slow behaviour was when I was exceeding the GPU memory of my computer, which put the OS in a memory thrashing loop. To check that I used GPU-Z that can display GPU memory usage. What you can try is edit the file named "lua/5.2/grbv/boards.lua" (not "lua/5.2/boards.lua"), locate two "4096" numbers, and change these to 256. If that fixes the problem, then it was memory thrashing. You can then try to increment the values by a factor of two to get better rendering quality (512, 1024, 2048).
