Tag: interactive media

Posted on

node.js: including files

The old way…

By Udo G at Stack Overflow

from: http://stackoverflow.com/questions/5797852/in-node-js-how-do-i-include-functions-from-my-other-files

If, despite all the other answers, you still want to traditionally include a file in a node.js source file, you can use this:

<code>var fs = require('fs'); // file is included here: eval(fs.readFileSync('tools.js')+'');</code>
  • The empty string concatenation +'' is necessary to get the file content as a string and not an object (you can also use .toString() if you prefer).
  • The eval() can’t be used inside a function and must be called inside the global scope otherwise no functions or variables will be accessible (i.e. you can’t create a include() utility function or something like that).

Please note that in most cases this is bad practice and you should instead write a module. However, there are rare situations, where pollution of your local context/namespace is what you really want.

share|improve this answer
answered Apr 27 ’11 at 20:13
Udo G
1,275319
4
Cool, this is useful for quick’n’dirty putting JS libs designed for client-side into a node.js app without the need of maintaining a Node-styled fork. – Kos Dec 11 ’11 at 13:24
1
The “+”” is just a shortcut to force string casting. The more readable solution would be “String(fs.readFileSync(‘tools.js’))” or if the read.FileSync returns an object then “fs.readFileSync(‘tools.js’).toString()” should also work since toString is attached to the base Object prototype (i.e Object.prototype.toString). – Evan Plaice Jan 20 at 23:22
-1 Blindly importing JS into the global namespace can open the code to unintended naming conflicts. If the code in the tools.js file were written in object literal format you could assign them to a local variable which works like a pseudo-namespace. Also, I don’t really think the eval is required (masylum’s code makes it seem like the code is already eval’d during the require). I think you’re import/eval-ing the code with require, casting that code back to string and eval-ing it again just to pidgeonhole it into the global namespace. Looks like you’re doing it wrong. – Evan Plaice Jan 20 at 23:31
1
I just answered the original question, which is about including code, not writing modules. The former can have advantages in certain situations. Also, your assumption about require is wrong: The code is certainly eval’d, but it remains in it’s own namespace and has no way to “pollute” the namespace of the calling context, hence you need to eval() it yourself. In most cases using the method described in my anwer is bad practice but it’s not me that should decide if it is for TIMEX. – Udo G Jan 21 at 17:03
1
@EvanPlaice: do you have a better suggestion which actually answers the question? If you need to include a file which is not a module, do you have a better approach than this? Otherwise, downvoting it seems absurd. – jalf Apr 21 at 11:04
Posted on

node.js reverse proxy in Ubuntu Apache2

(update) having problems with this when using socket.io from external clients. So it may be worth looking at the alternatives described in the Shelley Powers book on NODE.js

 original post

Here is now to set up a reverse proxy so that a node.js server is visible from the outside world. In our case we redirected any traffic with the subdirectory /nodejs/ to port 8124

for example, this web address http://zerokidz.com/nodejs/

Add the following to the /etc/apache2/sites-enabled/default file: (inside the section already set aside for the virtual host zerokidz)

ProxyPass /nodejs/ http://127.0.0.1:8124/
ProxyPassReverse /nodejs/ http://127.0.0.1:8124/
<Proxy *>
 Order deny,allow
 Allow from all
</Proxy>

So it will look something like this:

<VirtualHost *:80>
  ServerName www.zerokidz.com
  ServerAlias zerokidz.com *.zerokidz.com
  DocumentRoot /home/tkzic/public_html/zerokidz

# Nodejs reverse proxy rule
# sends all traffic for zerokidz.com/nodejs
# to the nodejs server on port 8124

ProxyPass /nodejs/ http://127.0.0.1:8124/
  ProxyPassReverse /nodejs/ http://127.0.0.1:8124/
  <Proxy *>
    Order deny,allow
    Allow from all
  </Proxy>

</VirtualHost>

Then restart apache, of course

Posted on

Slow data

notes

Examples of slow data streams.

  • bicycle wheel sensor that triggers once per rotation
  • The data stream from an OBD-II scanner which can only be polled every 300ms or slower
  • a traffic sensor on a quiet street

There aren’t enough data points to use typically smoothing methods like moving average or logarithmic smoothing. Here are 2 ideas for increasing data points using repetition:

  • feed the data into the right inlet of an [f] object to set its value. The left inlet receives the output of a [metro] set at the desired stream rate. Then the output of the [f] object can be smoothed using conventional methods.
  • convert data to a signal using [sig~] then smooth using [slider~] or [rampsmooth~] then convert back to float using the right outlet of [number~]

 

Posted on

OBD – speeding up data requests – part 2

notes

AT commands which may help speed things up…

AT0, AT1 and AT2 [ Adaptive Timing control ]

When receiving responses from a vehicle, the ELM327 has traditionally waited the time set by the AT ST hh setting for a response. To ensure that the IC would work with a wide variety of vehicles, the default value was set to a conservative (slow) value. Although it was adjustable, many people did not have the equipment or experience to determine a better value.

The Adaptive Timing feature automatically sets the timeout value for you, to a value that is based on the actual response times that your vehicle is responding in. As conditions such as bus loading, etc. change, the algorithm learns from them, and makes appropriate adjustments. Note that it always uses your AT ST hh setting as the maximum setting, and will never choose one which is longer.

There are three adaptive timing settings that are available for use. By default, Adaptive Timing option 1 (AT1) is enabled, and is the recommended setting. AT0 is used to disable Adaptive timing (so the timeout

is always as set by AT ST), while AT2 is a more aggressive version of AT1 (the effect is more noticeable for very slow connections – you may not see much difference with faster OBD systems). The J1939 protocol does not support Adaptive Timing – it uses fixed timeouts as set in the standard.

 

BRD hh [ try Baud Rate Divisor hh ]

This command is used to change the RS232 baud rate divisor to the hex value provided by hh, while under computer control. It is not intended for casual experimenting – if you wish to change the baud rate from a terminal program, you should use PP 0C.

Since some interface circuits are not able to operate at high data rates, the BRD command uses a sequence of sends and receives to test the interface, with any failure resulting in a fallback to the previous baud rate. This allows several baud rates to be tested and a reliable one chosen for the communications. The entire process is described in detail in the ‘Using Higher RS232 Baud Rates’ section, on pages 59 and 60.

If successful, the actual baud rate (in kbps) will be 4000 divided by the divisor (hh).

 Repeated commands

One other feature of the ELM327 is the ability to repeat any command (AT or OBD) when only a single carriage return character is received. If you have sent a command (for example, 01 0C to obtain the rpm), you do not have to resend the entire command in order to resend it to the vehicle – simply send a carriage return character, and the ELM327 will repeat the command for you. The memory buffer only remembers the one command – there is no provision in the current ELM327 to provide storage for any more.

 

S0 and S1 [ printing of Spaces off or on ]

These commands control whether or not space characters are inserted in the ECU response.

The ELM327 normally reports ECU responses as a series of hex characters that are separated by space characters (to improve readability), but messages can be transferred much more quickly if every third byte (the space) is removed. While this makes the message less readable for humans, it can provide significant improvements for computer processing of the data. By default, spaces are on (S1), and space characters are inserted in every response.

 

Posted on

OBD – speeding up data requests

Version 1.3 of the ELM327 introduced a way to speed up the retrieval of information, if you know how many responses to expect. By telling the ELM327 how many lines of data to receive, it knows when it is finished, so does not have to go through the final timeout, waiting for data that is not coming. Simply add a single hex digit after the OBD request bytes – the value of the digit providing the maximum number of responses to obtain, and the ELM327 does the rest. For example, if you know that there is only one response coming for the engine temperature request that was previously discussed, you can now send:

>01 05 1

and the ELM327 will return immediately after obtaining only one response. This may save a considerable amount of time, as the default time for the AT ST timer is 200 msec. (The ELM327 still sets the timer after sending the request, but that is only in case the single response does not arrive.)

Some protocols (like J1850 PWM) require an acknowledgement from the ELM327 for every message sent. If you provide a number for the responses that is too small, the ELM327 will return to the prompt too early, and you may cause bus

congestion while the ECU tries several times to resend the messages that were not acknowledged. For this reason, you must know how many responses to expect before using this feature.

As an example, consider a request for the vehicle identification number (VIN). This number is 17 digits long, and typically takes 5 lines of data to be represented. It is obtained with mode 09, PID 02, and should be requested with:

>09 02

or with:

>09 02 5

if you know that there are five lines of data coming. If you should mistakenly send 09 02 1, you might cause problems.

This ability to specify the number of responses was really added with the programmer in mind. An interface routine can determine how many responses to expect for a specific request, and then store that information for use with subsequent requests. That number can then be added to the requests and the response time can be optimized. For an individual trying to obtain a few trouble codes, the savings are not really worth the trouble, and it’s easiest to use the old way to make a request.

We offer one additional warning when trying to optimize the speed at which you obtain information from vehicles. Prior to the APR2002 release of the J1979 standard, sending J1850 requests more frequently than every 100 msec was forbidden. With the APR2002 update, scan tools were allowed to send the next request without delay if it was determined that all the responses to the previous request had been received. Vehicles made prior to this time may not be able to tolerate requests at too fast a rate, so use caution with them.