Saturday, January 24, 2015

Command settings for RTC on linux

Beaglebone Black RTC



This is the command I use to setup my Beaglebone with RTC DS133833.

Set Date and Time manually:

date --set 2015-01-23
date --set 21:08:00

Change region/timezone:

dpkg-reconfigure tzdata

Read RTC date time value:

hwclock -r -f /dev/rtc1

Write date time value to RTC:

hwclock -w -f /dev/rtc1

another command is

hwclock -s -f /dev/rtc1

To store date time in CMOS(Non-volatile memory):

hwclock --systohc

Import Project From Eclipse ADT to Android Studio

It is recommended to migrate from Eclipse with ADT to Android Studio since it is now the official IDE for Android to receive all the latest IDE updates.

Android Studio Import Projects


To migrate existing Android projects, simply import them using Android Studio:

    In Android Studio, close any projects currently open. You should see the Welcome to Android Studio window.
    Click Import Non-Android Studio project.
    Locate the project you exported from Eclipse, expand it and select the target folder.
    No need to select the build.gradle file anymore.
    click OK and Android Studio will do the rest.

Android Studio properly updates the project structure and creates the appropriate Gradle build file.

Download Android Studio: https://developer.android.com/sdk/index.html

Thursday, January 22, 2015

Nucleus: New PS3 Emulator

Afer rpcs3 which now able to boot first coomercial game, now we have another newcomer in PS3 scene called Nucleus.



This project focuses on PlayStation 3 emulation. Please, understand that I'm not interested on providing support, releases, or attention to any comments, issues or pull requests for now.

Limitations:

Memory: Nucleus emulates the PS3 user-mode environment, which uses 32-bit addresses. This reflects on the CPU / Memory related code, and could cause issues if you use it for other platforms, or for designing a low-level PS3 emulator.
Portability: Nucleus assumes that the host system runs on a low endian CPU, with 64-bit addresses.

Nucleus Git Changelog:

* Reorganizing detected platforms/compilers
* Added LLVM dependency and a new language

Download: http://down.emucr.com/v3/5651876045389824
Source: https://github.com/AlexAltea/nucleus

Wednesday, January 21, 2015

7.2 Conclusion


In this thesis, the TCP/IP was used on top of delay tolerant network fundamentals where store and forward operation perform by data synchronization at each mail server. This approach enables the email flow through the offline mail server to infomediary device and then to the online mail server and internet. The user registration page is implemented at online mail server and accessible from online mail server local area network or from the internet. The email data can remain in the mail server more than one week time delay until it synchronized with infomediary device. Limitation size of the offline email system file attachment is 10MB and total email message is 50MB. This limitation is depending on the size storage of the server computer. All types of data supported for uploading an attachment and system administrator can block various file extension such as bat, cmd, com, cpl, csh, exe, inf, lnk, msi, msp, reg, scf and scr from being uploaded as an email attachment. Multiple sender and receiver can send and receive emails simultaneously and supporting multiple communications between users successfully. Based on calculation, the maximum recommended speed of infomediary device movement through the Wi-Fi range of the server computer is 12.85 km/hr or less and depend on the hardware specifications such as Wi-Fi data transfer rate and storage read and write speed. This offline email system fulfills the objective of this thesis work where the system can be used at the area that has no internet connection such as rural area. This offline email system implementation based on DTN approach can be used for other web application such as blogging.

7.1 Future Work

7.      CONCLUSION

In this final chapter, a brief summary of the research and development work is provided. A recommendation for future work is concluded and conclusions of the research objectives and results are discussed.
In the beginning, an introduction and objective to the thesis work was presented. A comparison between TCP/IP and DTN was discussed. An email architecture and overview of similar work was given. Next, the design of TCP/IP mail system working using a DTN store and forward fundamentals is discussed including the network protocol design followed by offline email system detail design. The idea of using database synchronization as DTN store and forward fundamentals is discussed. Then, the system implementation issues and implementation details of server computer, web server application, mail server, mail client and database synchronization. Lastly, the system test and result of the offline email system was presented.

There is a possibility of this offline email system can support Government’s “Kampung Tanpa Wayar” project where it can benefit in term of cost to expand a portion of internet access such as the email application to rural area. It is also good to improve email security by implementing encrypt and decrypt process in data synchronization between Mail Server and infomediary device. A proper dedicated online mail server with a static IP internet connection is better to replace the current approach to reduce dependency to external services such as DtDNS. This will improve reliability of the system. Additional mail client feature can be added such as email labeling, priority email, send and achieve message etc. Database synchronization speed can be improved with better hardware, especially when dealing with many mail data and bigger attachment files. In the process of database synchronization, there is a need of checking the database path availability continuously between server computer and infomediary device. This process will consume much more power while in rural area there is are constrained that there is a need to conserve power consumption since the power in rural area mostly dependable to electric power generator. Instead of continuously checking the database path availability, the process can be done by checking the database path availability at a set of time or only when the infomediary device is available in the server computer network.

6.10 Summary


A brief result of the different testing approach was provided in this chapter 6. A demonstration setup was also explained to show various application scenarios of the offline email system. Next chapter, conclusions and future work are discussed.

Tuesday, January 20, 2015

6.9 Discussion of Results


The test result shows that user were able to register a new email account locally at online mail server or through internet. Email account created at online mail server is accessible at the offline mail server, online mail server and through internet after mail data synchronization between infomediary device and each mail server. Email system found to be successfully functional to send or receive email through the offline mail server, online mail server and internet. Pending email data is tested for a period of time and found to be able remains in the database and not discarded. Wireless LAN range between server computer access point and infomediary device for it to establish mail data synchronization is 95 Meters or less with a data rate transfer is 54 Mbps which is 54 megabits per second equal to 6.75 MBps which is 6.75 megabytes per second and limited by infomediary device storage write speed which is 2.03 Mbps. The recommended infomediary device move speed through the Wi-Fi range of the server computer is 3.57 m/s equal to 12.85 km/h or less to ensure the mail data synchronization is completed successfully. The maximum size of an email attachment is 10MB with total message size limit is 50MB. It is also recommended to limit the size to lower 10MB to prevent spam attack and viruses. Each email account size quota is set to 250MB. It is dependable on the server computer hard drive storage size. All tested emails are successfully sent and receive within the mail server email size limitation. This offline email system can upload any types of file and have the ability to block attachments with certain extensions on the mail server. Number of email connections is unlimited. It can send or receive emails multiple times without worrying of the mail data overwritten on the mail server database.

Sunday, January 18, 2015

BleachBit (Cruft Cleaner) - a CCleaner for Ubuntu

Windows users will be familiar with applications like CCleaner, which scan for and clean out junk files, empty folders, bloated caches, and obsolete packages. For a a similarly quick and effortless click n’ clean solution on Ubuntu try BleachBit.



It is a powerful tool, so do pay attention to what you’re cleaning. Don’t aimlessly check every box; not everything that it can clean needs to be. Play it smart; when in doubt, leave it out.

Install now: https://apps.ubuntu.com/cat/applications/bleachbit/

6.8 Multiple of Communications Test

This test is to check the maximum number of simultaneous SMTP connections to the server. An unlimited number of simultaneous connections will be allowed by configured mail server number of connection values to zero. This value is set to zero by default. This is to ensure no overwrite email occurs and check this offline email system capability of handling the same sender sent an email a few times to multiple receivers.
This test performed with a two way communication. The sender sends an email to receiver and receiver send email to sender at the same time. There are three scenarios tested which are between two users, four users and six users as shown in Figure 6.5. Another test is sender send multiple emails to the receiver to ensure are not overwritten in the mail server database.
Multiple of Communications Test

Figure 6.5: Multiple communication
Expected outcome from all three test samples as shown in Figure 6.5 as per below:
Test 1: User A1 successfully sends email to user B1, while user B1 successfully receives email from user A1 and vice versa.
Test 2: User A1 and A2 successfully sends email to user B1 and user B2, while user B1 and user B2 successfully receive email from user A1 and user A2 and vice versa.
Test 3: User A1, user A2 and user A3 successfully send email to user B1, user B2 and user B3, while user B1, user B2 and user B3 successfully receives email from user A1, user A2 and user A3 and vice versa.
Test 1 is to test two way communications between two users. User A1 successfully sends email to user B1, while user B1 successfully receives email from user A1 and vice versa. Test 2 is to test two way communications between four users. User A1 and A2 successfully sends email to user B1 and user B2, while user B1 and user B2 successfully receive email from user A1 and user A2 and vice versa. Test 3 is to test two way communications between six users. User A1, user A2 and user A3 successfully send email to user B1, user B2 and user B3, while user B1, user B2 and user B3 successfully receives email from user A1, user A2 and user A3 and vice versa. The result of multiple communication shown in Table 6.7. Test on multiple emails send from users at offline network environment to users at online network environment shows that the emails is successfully send and received. Test result is produced by actual conduct test.


Test
Sender
Receiver
Email delivery result
Sending email
Receive email
1
User A1
User B1
User A1 to User B1 - success
User B1 to User A1 - success
User B1 from User A1 - success
User A1 from User B1 - success
2
User A1
User B1
User A1 to User B1 - success
User B1 to User A1 - success
User B1 from User A1 - success
User A1 from User B1 - success
User B2
User A1 to User B2 - success
User B2 to User A1 - success
User A1 from User B2 - success
User B2 from User A1 - success
User A2
User B1
User A2 to User B1 - success
User B1 to User A2 - success
User B1 from User A2 - success
User A2 from User B1 - success
User B2
User A2 to User B2 - success
User B2 to User A2 - success
User B2 from User A2 - success
User A2 from User B2 - success
3
User A1
User B1
User A1 to User B1 - success
User B1 to User A1 - success
User B1 from User A1 - success
User A1 from User B1 - success
User B2
User A1 to User B2 - success
User B2 to User A1 - success
User B2 from User A1 - success
User A1 from User B2 - success
User B3
User A1 to User B3 - success
User B3 to User A1 - success
User B3 from User A1 - success
User A1 from User B3 - success
User A2
User B1
User A2 to User B1 - success
User B1 to User A2 - success
User B1 from User A2 - success
User A2 from User B1 - success
User B2
User A2 to User B2 - success
User B2 to User A2 - success
User B2 from User A2 - success
User A2 from User B2 - success
User B3
User A2 to User B3 - success
User B3 to User A2 - success
User B3 from User A2 - success
User A2 from User B3 - success
User A3
User B1
User A3 to User B1 - success
User B1 to User A3 - success
User B1 from User A3 - success
User A3 from User B1 - success
User B2
User A3 to User B2 - success
User B2 to User A3 - success
User B2 from User A3 - success
User A3 from User B2 - success
User B3
User A3 to User B3 - success
User B3 to User A3 - success
User B3 from User A3 - success
User A3 from User B3 - success
Table 6.7: Multiple communication test result