SimpleLan and PicAxe

6jones720 what is the price of the picdem.net module?
demonicpicaxeguy the 28X1 will work fine with the SerIn funtion, but, going back to first discussions, if we define a communication protocol there shouldn't be any problems.
 
i do believe that there is a handfull of pics that could be connected to an adsl modem via an ethernet port i think the pic18lf452 has usb and ethernet
doing a simple serial tcp/ip handler shouldn't be all that hard... be interesting to look at, anyone know anything about tcp/ip in any great depth?
 
We dont need static ips to contact the picaxes.
If you just have a central server that you can send a heartbeat to every xminutes, it can remember where this picaxe is.

But a problem is with UDP connections, you cannot recieve behind a NAT firewall/router without having a port forwarded to your local ip, and besides not all people are able to forward ports, it will mean the picaxes have to use different ports, if there are more than one on a nat network.

If it were TCP we could make a chat server instead where they can connect to and download messenges, even without an incoming port, but with stateless udp this is not possible.

Ofcause oneway sensors could still work without an incoming port, sensors, alarms, weather stations, etc. dont need orders from outside they just sent their data over and over again.
 
MORA99 you seem to forget that most firewall are using statefull filtering rules, that is that if a UDP packet goes out the firewall to a certain IP the firewall will allow a UDP packet in from that sepcific IP.

As an example of that, the VoIP applications (Skype, GoogleTalk, etc.) are all using UDP for voice transfer. You don't need to change anything in your firewall/adsl/router in order for the software to work.

So, a UDP chat (multiplexing) server can actually be used to pass message among the PicAxe chips. If we define a simple 'chat' protocol we can have PicAxes (either with TCP/IP modules, hacked wifi-routers, connected to serial port of computers) talking to each other. Not bad ;-)
 
DPG : PICmicro's only work as USB Slaves so cannot function as the USB Host they'd need to be to talk to an ADSL modem.

c6jones720 : I'd like to get into reprogramming the PICAXE.Net but haven't got round to it. It's quite an expensive platform compared to what else there is these days.

There's definitely a requirement for a PICAXE friendly ethernet interface. As soon as serial is involved it all gets very complex unless designed around the PICAXE limitations. Many of the ethernet modules are re-flashable but writing PICAXE friendly software would be a challenge.

Using the ENC28J60 and a micro between that and a PICAXE would be the best approach IMO. Any cheap board with an ENC28J60, RJ45 and a programmable micro on board would be what I'd target.

There are still issues. Simple UDP in and out would be seen as being quite expensive for what it is. Adding Telnet and Web server would be an awful lot of work without a reference design to work to.

The most profitable approach may be to talk to manufacturers like SimpleLan and explain what needs to be done to make it very PICAXE friendly. They've already got all the skills necessary.
 
I think Hippys right, the picdem/picaxe.net are expensive devices £81.99

http://www.microchipdirect.com/ProductDetails.aspx?Catalog=BuyMicrochip&Category=PIC%20Proof%20of%20Concept%20Kits&mid=13

I bought one of each last year for hardware network development at work. I think the price comes from the electronics because they used a RTL8019 chip to do all the hard work. They are hard to come by these days.

I ended up getting the book TCP/IP lean which basically details how to do networking on many different processors. The only problem is that a lot of the internet comms was done with old fashioned dial ups using TCP/IP over SLIP. Its probably worth having a look at.
 
If we could contact the manufacture of SimpleLan what would be the things we soudl ask in order to make the module PicAxe-friendly?
 
The main thing necessary is that it never sends anything to the PICAXE until the PICAXE has indicated it wants it, and is then ready for it, coupled with a mechanism to let the PICAXE know there is something there which can be asked for - this is assuming a normal non-X1 PICAXE without HSERIN.

Importantly though when trying to get a company to do something, a convincing case has got to made for that, either a business / economic case, or a direct appeal to their engineering side that it's a worthwhile or useful thing to be done.

That means having to be able to very formally define for them what the issues are, what the problem is, how it could be solved, what solutions would not work or not be acceptable, and why it is necessary or desirable for them to do this, along with the benefits gained.

If you don't want your effort shown the door, it helps to build up a rapport and relationship with the company themselves and to be very knowledgeable about the product and how it works before 'dictating' to them.

Business influence is a strong force - "If you add this I'll buy a million pieces, or go somewhere else" - but individuals can have a much tougher time of it and have to be more creative in their approach.

Once you have your PICAXE-SimpleLan UDP passing system working you'll be able to identify what the weak points are and how it could be better or more PICAXE friendly, and that's when you'll be in a good position to be able to define what needs to be done. You should also be able to determine if a solution proposed is good enough or not, so you can stand your ground and not be 'fobbed off'. But don't be too inflexible; it's all about persuasion, usually of the subtle variety - You're helping them make their product better, not criticising what it lacks, inviting them to add things not demanding.

A good course is to convince someone that your good idea is their good idea :-)

And remember, "wouldn't it be nice if a PICAXE ..." is often far more productive than, "If you don't add this, I'm off elsewhere".

Of course, you could just say, "add this", and you may get lucky, but you don't want the door shut permanently after the first approach.
 
Well, good news Hippy. In order to read aqny of the data holding registers of the module, either the Web Variables or the UDP message Variables, is by asking the module to send you the data by first sending a command to it (Serout). Also, there is a special register (1byte) that indicates, according to the bit's values, if there was an update of the registers through the Web Interface or through a UDP message. Pretty handy I guess.

You are right about your approach and the way to ask 'nicely' for things to be added. I would be nice for Rev-Ed to re-brand the module and sell it as a PicAxe Ethernet board. PicAxeNET is, at least for me, an expensive approach to Ethernet and Networking.

But as you said, we first need to define exactly what we would like to see in that module.
 
I spoke to and exchanged emails with Scott at Avcom Tec yesterday (and ordered their last two SimpleLAN parts before they resupply later this week with 500 more). I got the impression that it was a very small company, and so they might be open to suggestions. From reading the manual, it appears that its serial interface is oriented to the BASIC Stamp 2, and so uses serial out from the SimpleLAN side which terminates variable length data with a carriage-return. I'm not experienced enough to be sure how cumbersome this would be on non-hserin-enabled picaxes. But there are a lot of features, and it might take the code-space of a 28X1 to exercise them fully anyway. This looks like a very exciting part to go with a picaxe network--what the SitePlayer should have been 5 years ago.
 
lbenson yes, they seem like a small size company, which is not bad.

So, you got 2 for your self, huh? Any projects you have in mind for them?

They only way, based on my experience, to bypass the serin waiting is to know the size of the data you are expecting to receive.
 
steliosm--my project is similar to yours, remotely monitoring/controlling events about the house, e.g., temperature, working of water pump, boiler, sump pumps (maybe reading electric meter based on recent thread). This is for a house that is not occupied for part of the year, and I particularly would like to receive notice if the temperature drops close to freezing or if the water pump runs continually, indicating a pipe break. The house is checked periodically, but it could be several weeks before a boiler failure was noticed (the boiler system has antifreeze in it). In an additional correspondence to your project, I am looking into installing OPENWRT on one of the NSLU2s which I have been using for years with the Unslung software. It is still an alpha release on the NSLU2, tho, and I am not a linux guru. SimpleLAN may be able to do most of what I wanted to do with the NSLU2, and would probably be much easier to control.

 
<i>&quot;Has anyone looked at the ENC28J60...? </i>

Thanks for the lead. That's a very interesting chip.

To ice the cake, it's even available in a DIP package! You don't see that much, these days, for the more interesting chips. (Have I mentioned, lately, that I hate working with SMT parts?)

Data sheet here: <A href='http://ww1.microchip.com/downloads/en/DeviceDoc/39662b.pdf' Target=_Blank>External Web Link</a>

In a 28-pin SPDIP package, $3.97 from Microchip Direct: <A href='http://www.microchipdirect.com/productsearch.aspx?Keywords=enc28j60' Target=_Blank>External Web Link</a>

Again, thanks!

Tom


 
The ENC28J60 is what I'd use if I wanted a directly controlled ethernet interface, but I'm not sure a non-X1 PICAXE can handle it. It has quite a lot of initialisation required. I've got some but haven't tried anything because ...

The problem with it is that it needs suitable &quot;magnetics&quot; ( separate or built into the RJ45 ) and they need to be of a very particular type, and cost more than the chip does. Some of the resistor values are a little specific and unusual as well.

It <i>should </i> be possible to wire directly to a hub using just R's and C's but ( AVR and FPGA bit-banged ethernet can do that ), but the experts suggest this won't work with in this case :-(

Easiest ( but more expensive ) solution is to buy a PacketWhacker or similar which is an ENC28J60 plus magnetics and RJ45 on a pre-built board. The Microchip PICDEM.Net 2 uses it now rather than the Realtek interface.
 
demonicpicaxeguy: you will still have to roll out your TCP/IP stack. This chip will only give you Ethernet access. Through the SPI interface you will have to read/write the data registers of the chip and act accordingly.

If you would like to move a step 'up' you could have a look at the WIZnet chip <A href='http://www.wiznet.co.kr/pro_iin_W3150.htm' Target=_Blank>External Web Link</a> (and modules <A href='http://www.wiznet.co.kr/pro_iin_NM7010B.htm' Target=_Blank>External Web Link</a>) that have TCP/IP embedded in a chip. This is a nice challenge for the PicAxe and it seems doable.

Last, I will say that if you need results fast get something that is already done and works. I you just want to play around there are a lot of chips with to do it.
 
After lots of searching on the internet, I still haven't found anything as good a value as this Simplelan. Up till now I've gone for a free solution, which is an old PC (went to local computer store, guy showed me the great wall of old PCs and said take em all). But wanting to be kind to the environment I still feel a bit guilty about the few lumps of coal my PC eats every day. Stelios has got this down to minimal power with just a router and a simplelan. Huge amounts of data are not needed in home automation - some of my most critical devices like the tank overflow sensor only send 4 bytes an hour. But the data needs to get through.

The solar power radio repeater is now stable after 2 days of testing <A href='http://www.geocities.com/drvernacula/315_mhz_solar_powered_radio_rptr.htm' Target=_Blank>External Web Link</a> and may be getting close to getting 10-15 boards made up for wider field trials. Three have been happily bouncing signals around over about an acre of hilly land.

I am very interested in Stelios' experiments, as I think the simplelan can be interfaced to a wireless mesh with just one picaxe and hence lead to a modular home automation system with no wires.

How are things going with the variable length packets and Serin?
 
I did a lot of researching as well in order to find an easy and cheap way to interface the PicAxe with the Internet. Siteplayer was one of the solutions, but I had to fork out about 60euros here in my country in order to get it. Almost the same price for the Xport module. So, site player was out of the picture. Xport is a 3.3V TTL device, so that would introduce headaches to interface it with PicAxe. Although, some versions are said to be 5V tolerant.

The HomeMonitor project (<A href='http://www.steliosm.net/home_monitor.html' Target=_Blank>External Web Link</a>) doesn't use mush data either. It's only about 7 bytes of data. The thing was that I needed a way to saw this data in a nice picture. I could have used a PC here in my home to render the graphics and then use a DynDNS technic to make this data available to me and everyone interested, as I did in the first place. The work-around was to send the data off to a server located somewhere in the cyberscape. When the SimpleLan is able to open TCP connections to remote hosts the wifi router will be out of the picture.

As for the variable data length that is a problem. I'm thinking of slowing down the rate of the serial connection (600bps) and try to read one byte at a time off the serial and check if that byte is CR character or not. I'm afraid that the PicAxe , especially the 08M I'm using, is not up to that job. Also, I will need to have a buffer to push the bytes in, like an EEPROM memory. SimpleLan can hold up to 64bytes in a single register! I'm think I'll have to stick with a predefined data communication-type protocol. The good thing is that through the Web Interface I can control the size of data to be sent back to the PicAxe. Through UDP packets, this cannot be done, although SimpleLan can accept up to 64bytes of data.
 
stelios (and others)--I have two questions. Your use of UDP from the SimpleLAN implies that you have an always-on listener somewhere. Is this part of your Python/Perl/PHP setup? How do you get a UDP message somewhere where you can use it?

The second question forks away from SimpleLAN, but continues the issue of how to get a message from a picaxe to anywhere in the world. Suppose you could use a picaxe (28X1) to get a serial dialup modem to connect to an internet provider--how difficult would it be to do the negotiations and package wrapping needed to send a UDP message, or even just an email? I notice that a UDP packet (http://en.wikipedia.org/wiki/User_Datagram_Protocol) does not itself include an IP address.

Lance

 
Yes, a UDP based communication will need a UDP server to multiplex the messages across each client. Sort of an IRC/Chat server that receives messages and broadcasts to the clents connected to it. For my tests I used the following Python code:

<code><pre><font size=2 face='Courier'>
#!/usr/bin/python

#
# Simple UDP server to test the SimpleLan UDP functions.
# by Stelios M.
#

# Import the modules we need
import socket, traceback

# Create the IP/Port bindings
host = ''
port = 22002

# Create a UDP socket and set it to Listen
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind((host, port))

# Loop always
while 1:
try:
message, address = s.recvfrom(8192)
print &quot;Got data from &quot;, address
print &quot;Data: &quot;, message
except (KeyboardInterrupt, SystemExit):
raise
except:
traceback.print_exc()
</font></pre></code>

This code is just for testing, I don't have it running on a machine. Actually, as you see it doesn't do anything, just prints out the data that the PicAxe sent through UDP.

AS for the dialup you are proposing, you will need to implement the WAN protocol (PPP in most cases) and on top of that the whole TCP/IP stack. Then, after having a PPP and TCP/IP stack you should write the SMTP protocol in order to send the email. It would be much easier to connect the SimpleLan on a broadband router that has an Ethernet port and do what you need to do (eg. send emails).
 
A crash-course guide to TCP/IP networking, although it's obviously not as simple or as cleanly implemented as this may suggest -

UDP packets only exist within one's own computer, notionally travelling from port to port as per the numbers specified in the UDP packet ... until they are dropped into a TCP packet wrapper with IP addresses, and can thus pass further up the network.

Someone receiving a TCP packet would normally filter anything which wasn't sent to their IP address and throw it away. Everything else gets the TCP wrapper stripped away and then it's thrown into their PC without the IP Addresses and the Port Numbers do the rest.

As UDP is wrapped in TCP to pass between IP addresses, IP is wrapped in Ethernet packets to pass between Network Interface Cards ( NIC's ) on the network where they use the MAC address to decide where they should be going. A NIC throws away any Ethernet packet not addressed to its NIC. There are a set of protocols ( ARP, RARP ) which allow a sending PC to determine the MAC of a PC which has a particular IP address and vice-versa so the sending NIC knows where to send a packet.

When it comes to sending UDP via your ISP to somewhere, it still needs wrapping in a TCP wrapper but if going via modem there is no MAC address for a modem so it simply sends it as a packet of serial data to the ISP. The ISP's modem gets the serial data, extracts the TCP packet, works out the MAC address of where it's to go from the IP adress provided, adds that on and pushes it off. It fakes a MAC address for the modem so response packets can be directed back and when they appear they are routed back up the modem to the sending PC.

For a PC talking to the NIC hardware ( bypassing the OS ) or a PICAXE talking to an ENC28J60, what gets written to the NIC is an Ethernet packet, so the PC/PICAXE has to build a UDP packet, add the IP addresses to create a TCP packet, add the MAC addresses to create an Ethernet packet and then send it to the NIC as a chunk, which gets buffered and then sent out.

On receipt, a NIC indicates it has received a packet, and then allows the PC/PICAXE to take one from its buffer. An entire Ethernet packet received is handed over. The TCP packet has to be extracted from that, and then the UDP packet, and then whatever the UDP data signifies can be dealt with.

To prevent the NIC shouting &quot;got one&quot; on every packet, it can be told to accept only packets to its MAC address and to Broadcast addresses, and some are now clever enough to take a peek into every packet to see if the IP address is correct or not. Conversely, a NIC can be told to act in &quot;promiscuous mode&quot; where it will catch every packet going by regardless of who it's really for, which is what Packet Sniffers do.

Creation of a packet to pass to a NIC to be sent somewhere is easy if the IP addresses and MAC addresses of the destination are known, but if not then it's necessary to use ARP and RARP mechanisms to discover those things. It's also necessary to ensure all sent packets have the right checksums and that's not always an easy task.

The IP of TCP/IP is a layer on top of TCP just as UDP, ARP and RARP are, but considerably more complex, with error checking, requests for re-transmission and handling data arriving in the wrong order. From the networking point of view it's just the same as the rest though, an IP packet gets wrapped in a TCP packet and so on.

The basic entity of the modern familiar network is TCP, carrying other packet types within it. As long as TCP packets can be packaged up and unpackaged at the other end, no matter what means is used ( NIC, modem, wireless etc ), everyone is happy and has not a care in the world over how packets got into the pool of those waiting to be dealt with; in that pool, all packets look just the same, envelopes waiting to be opened.

It's quite an elegant and simple system, but quite complex to implement and get right.
 
Stelios--It would clearly be easier to hook up the SimpleLAN to broadband, and use its email function, but I don't expect to have broadband service in the house in the winter when I'm not present. A dial-up option could give me good value, but might be too difficult to implement. Thanks for providing your python UDP listener code.

It is possible that this Best Data &quot;SMART ONE 56K BROADBAND BACKUP &amp; INTERNET SHARING MODEM&quot; would work: http://www.bestdata.com/index.php?file=c-allproddesc&amp;iProductId=16156 . Available here: http://www.buy.com/retail/product.asp?sku=10359021&amp;SearchEngine=Shopper&amp;SearchTerm=10359021&amp;Type=PE&amp;Category=Comp&amp;dcaid=15889
for $65.99 (USD).




Edited by - lbenson on 15/08/2007 18:09:19
 
If you don't have broadband and need SimpleLan ( or whatever ) to send out packets or email via a modem, somewhere on the local network you'll need something which can do 'dial on demand', make the connection, pass the data on, then hang up.

SimpleLan and their ilk can create the necessary packets and carry on the necessary communications but cannot establish the connections themselves.

PC's, some hardware or PC-based firewalls and routers do dial on demand, and I expect the NSLU2 can be configured to if modded to attach a modem via serial and the right software were found

In the good old days before ASDL there was ISDN which appeared to be an always on connection but was dial on demand with a very quick connection time.

One problem of dial on demand used to be that Windows was notorious for broadcasting &quot;I'm here!&quot; and &quot;Is anyone out there?&quot; packets at a frequent rate which can cause dial-out for no good reason.
 
I have a &quot;dial backup&quot; router (sorry, don't remember the model - and it's 400 miles away) that works fine. It stores the ISP's phone number, your ID, your password and it dials on demand. I haven't used it much, as it was a proof-of-concept project. I think it was less than $20US on eBay. Some of the dial routers include a modem; most of the ones I've seen do not.

You never know what speed the dial connection will be (my ISP still has some modems that always answer at 14.4). This is not a problem for PICAXE use, as their data rates will probably be less than the lowest dialup speed you get ;-)

John
 
The Internet sharing router should work with the PicAxe and SimpleLan. On the other hand, if you only need to receive data on-the-cheap you could research on an SMS aproach. Having an old mobile phone serially connected with the PicAxe and sending SMSs sounds like a nice a cheap way to go.
 
Stelios--I had thought (in another context) of using text messaging (SMS) from a cell phone as a backup to an internet message system, but don't have a serial-controllable cell phone. Do you perhaps know of some phone models which might be for sale cheap on ebay which would be picaxe controllable, preferrably ones which could have a pay-as-you-go plan? Of course, I realize that you, in Greece, are unlikely to know what plans are available to me in the U.S. and Canada.

For my empty-house monitoring project, I decided that the easiest thing will be (as suggested) an always-on internet connection, and a SimpleLAN module controlled by a picaxe 28X1, so I have arranged to switch to a less expensive provider. Now I am eagerly awaiting the arrival of my parts. I am counting on the email feature of the SimpleLAN, since I'm not sure that my provider will allow inbound-initiated access to view my data on the SimpleLAN web pages. I can process the email data to display it on another site. If I must do this, control from the outside will not be possible, but that's not a real problem at this stage.

Lance
 
Lance, the old Nokia models can be easily controlled with a serial connection. A good site to get more information would be Gnokki (<A href='http://gnokii.org/' Target=_Blank>External Web Link</a>). It s suite of tools to send/receive SMS messages through linux and also covers some issues with certain devices.

Accepting incoming connections shouldn't be a problem if you know the IP to connect to.
 
&gt;Accepting incoming connections shouldn't be a problem if you know the IP to connect to.

&quot;Shouldn't be&quot; is the key. I'm not sure what the case will be here in Nova Scotia, but in Washington DC, Verizon DSL would not allow connections initiated from the outside (without extra $$$ paid), and I've heard that the same is true for many other providers in the U.S.
 
The &quot;outside connection&quot; rule sometimes depends on the type of connection. Many ISP's do not allow connecting to port 80 (web server) incoming, but allow other connections (ports used for multi-player games and the port used for SQL Server, for example).

If you can change the port being connected to (either on the SampleLan or via a translation table in the router), you can get to a web server on your internal network from the outside.

Depending on the router, you may have to put the SimpleLan in the unprotected DMZ.

John
 
The chips is being sold on ebay too, may be easyier for non us customers than cheating their order form :)

&quot;go to www.ebay.com?wp_ml=0 and search SimpleLan.&quot; (From scott at avcom).


Is there any sample code avaliable that shows how to recieve/send udp with the picaxe ?
 
Stelios has code at <A href='http://www.steliosm.net/picaxelan.html' Target=_Blank>External Web Link</a>, but this just sends to a local listener. It is unclear to me how one would send a UDP message to an external IP address.
 
Lance, of course you can send UDP packets outside the local network. You just need to change the IP address of the remote end. I had the UDP listener running in a friend's LAN and I had no problems sending him packets. You see, the SimpleLan configuration, the one which is done through the win32 application, accepts a Default Gateway value which is the key to send and receive UDP packets from remote locations :-)

Just a simple flow of sending UDP packets to remote locations:

-SimpleLan checks the listener's IP.
-It sees that the IP does not belong to the Local Network.
-It constructs the UDP packet (datagram) with SourceIP, SourcePort, RemoteIP, RemotePort, Data and puts it inside an Ethernet frame. -Inside that Ethernet frame SimpleLan adds his own MAC address (Source MAC) plus the Default Gateway MAC address (Remote MAC) (which can find out by doing an ARP request) and sends the frame away.
-The Defalt Gateway, which is actually a router, rec$eives the packet, strips off the Ethernet frame and reads the UDP packet. Retrieves the RemoteIP and sends the packet away :-)

Simple as that (OK, I admit, I left out some details on the Router part...)

MORA99 I got my module for the ebay too :-) Check the code in my site and of course post your comments/questions so I can help you.
 
Cool, looks &quot;simple&quot; enough.
Have you tried recieving UDP packets ?

I have ordered 2 from ebay, will probaly be 1-2weeks before they arraive here.
 
You got two? Already? I'm thinking or ordering a couple more but I need to find an excuse (project) first :-)

I'm actually doing some tests right now, I'll let every one know how it goes. Shouldn't be difficult though.

demonicpicaxeguy I still haven't posted my UDP receiving routines for the PicAxe:-) The fun just begins...
 
I ordered two to see them &quot;talk together&quot;, then they will be moved to something else.

One will control some status leds that I use to keep an eye on all the servers im surposed to keep running.

Dont know about the other, maybe control some relays so I can free up a more expensive board currently controlling them.
 
Stelios--Thanks for your assurance that UDP messages may be sent outside, and for your explanation. There's still one part of it that I don't understand. You say &quot;SimpleLan checks the listener's IP&quot;, but since SimpleLAN is initiating the message, how does it know what the listener's IP is? Is this part of the router magic? Does the router have to be configured (other than with SimpleLAN) so that it knows that a certain port (specified in the UDP message) is associated with a particular IP address (which could be either local or remote)? The &quot;Default Gateway&quot; I thought would be your local network router address. I don't see in the PC-to-SimpleLAN setup that there is a way to set a UDP IP destination, so I'm thinking that the router has to have been told what IP address goes with what port. Is this the way it is done?

Lance
 
Lance, you are actually telling SimpleLan where to send the message when you are constructing the message. Take for example the code below:

<code><pre><font size=2 face='Courier'>
serout 2, t2400, (&quot;!AT0WBM:This is PicAxe!&quot;, 13)
serout 2, t2400, (&quot;!AT0WBI:192.168.2.1&quot;, 13)
serout 2, t2400, (&quot;!AT0SB&quot;)
</font></pre></code>

In the second line PicAxe tells the SimpleLan where to send the UDP packet. It can be any IP you want it to be considering that there should a server to handle the packet.

The Default Gateway in most cases is the broadband router IP address. This IP address can be configured in the SimpleLan by the windows application that comes with SimpleLan. Here is the software if you want to have a look at it: <A href='http://www.avcomsmt.com/SimpleLan.zip' Target=_Blank>External Web Link</a>.
 
OK, let the <b>fun </b> begin :-)

I started playing around with reading values off the SimpleLan. While I wasn't expecting any problems, I can't figure out what might be wrong.

To start things from the beginning:
I am sending a value ('A') through the PicAxe to the module.
I can see the value ('A') through the web page from the module without problems.
I try to read the variable from the PicAxe but I receive back a different value. Using the debug I can see that I receive most of the times the ascii value 195 instead of 65 ('A') and in random order I also receive ascii value 13. I know that the SimpleLan ends each transmition with a CR character (that is variable contents + CR), so I should be receiving the same pattern of characters which is not happening.

This is the code I use:
<code><pre><font size=2 face='Courier'>
main:
'
' Ask for the Web Variable
'
' Write a value to the Variable
serout 2, t2400, (&quot;!AT0W20:A&quot;, 13)
' Request to read the Variable
serout 2, t2400, (&quot;!AT0R20&quot;, 13)
' Read the Variable
serin 3, t2400, b0
' Get a debug
debug
high 1
</font></pre></code>

Running the PicAxe at 8m and setting the serial speed at t1200 I get various results. Might be that serin is not that sable in 8m mode.

So, any ideas?
 
You must log in or register to reply here.
Back
Top